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FOREWORD 


This  guide  provides  an  introduction  to  scheduling  intended  for  use  by  government 
program  managers  and  industry  program  of  project  managers  and  their  respective  staffs. 
It  is  the  third  version  of  a  1986  publication  prepared  by  Mr.  David  D.  Acker,  Mr.  J.  Stanley 
Baumgartner,  and  Mr.  Michael  B.  Patterson.  A  second  version,  published  in  1994,  was 
prepared  by  Mr.  William  W.  Bahnmaier  and  Mr.  Paul  T.  McMahon. 

This  version  addresses  many  of  the  topics  contained  in  their  earlier  versions,  especially 
those  relating  to  the  different  types  of  scheduling  techniques.  The  major  difference 
between  this  and  the  previous  versions  is  the  treatment  of  scheduling  as  part  of  the 
acquisition  process  and  the  overall  program  management  effort,  particularly  as  it  relates 
to  the  planning  and  control  functions  of  program  management.  Scheduling  is  discussed 
in  the  context  of  the  development  of  integrated  master  plans  and  schedules,  the  risk 
management  process,  and  earned  value  management. 

This  guide  is  not  intended  as  a  detailed  treatment  of  scheduling  techniques.  Instead,  it  is 
more  of  a  primer  on  the  subject,  addressing  the  importance  of  scheduling  and  the 
application  of  basic  scheduling  techniques.  It  is  a  compilation  of  information  from  various 
sources,  and  hopefully  will  serve  as  a  starting  point  for  those  who  desire  to  delve  deeper 
into  the  various  scheduling  techniques. 

The  proliferation  of  microcomputers  has  greatly  enhanced  the  capability  of  managers  at  all 
levels  to  develop  and  analyze  schedules.  Chapter  9  provides  an  overview  of  the  types  of 
automated  tools  available  and  information  on  desirable  features  of  scheduling  software 
applications. 

This  document  reflects  the  efforts  of  many  people.  Mr.  William  W.  Bahnmaier  and  Mr. 
Paul  T.  McMahon  and  Lt  Col.  David  Bachman,  USAF,  of  the  DSMC  faculty  provided 
invaluable  strategic  guidance  and  advice.  Mr.  Gregory  T.  Caruth  of  the  DSMC  Press  was 
very  helpful  in  the  composition  of  the  guide.  SFC  Frances  M.  Battle,  USA,  provided 
desktop  publishing  skills.  Mr.  Van  Kinney,  Ms.  Joni  Forman  and  Mr.  Tom  Parry  of  the  OSD 
Acquisition,  Resources  and  Analysis  staff  provided  comments  on  the  draft  and  overall 
support  for  the  project.  Special  recognition  also  goes  to  the  Institute  for  Defense  Analysis 
team  of  Mr.  Lou  Simpleman,  Mr.  Jim  Lloyd,  Mr.  George  Tolis,  Ms.  Patti  Phillips,  Ms.  Tina 
Higgins,  and  Ms.  Yolanda  Prescott,  who  wrote,  edited,  and  prepared  the  major  portions 
of  the  text. 


Norman  A.  McDaniel 

Chair 

Program  Management  and  Leadership 
Department 


William  W.  Bahnmaier 

Editor 

Program  Management  and  Leadership 
Department 
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INTRODUCTION 


1.1  OVERVIEW 

In  its  simplest  form,  a  schedule  is  a  listing 
of  activities  and  events  organized  by  time. 
In  its  more  complex  form,  the  process  ex¬ 
amines  all  program  activities  and  their  re¬ 
lationships  to  each  other  in  terms  of  realis¬ 
tic  constraints  of  time,  funds,  and  people, 
i.e.,  resources.  In  program  management 
practice,  the  schedule  is  a  powerful  plan¬ 
ning,  control,  and  communications  tool 
that,  when  properly  executed,  supports 
time  and  cost  estimates,  opens  communi¬ 
cations  among  personnel  involved  in  pro¬ 
gram  activities,  and  establishes  a  commit¬ 
ment  to  program  activities. 

A  key  aspect  of  program  management  plan¬ 
ning,  scheduling  is  integral  to  a  program's 
acquisition  strategy  and  to  risk  manage¬ 
ment,  financial,  and  technical  management 
plans.  In  addition,  scheduling  is  an  impor¬ 
tant  element  of  the  other  management  func¬ 
tions:  organizing,  staffing,  controlling,  and 
leading.  For  example,  controlling  is  per¬ 
formed  to  keep  abreast  of  program  execu¬ 
tion.  To  achieve  this  goal,  it  is  necessary  to 
know  whether  the  program  is  behind,  on, 
or  ahead  of  schedule,  and  what  adjust¬ 
ments  are  necessary  to  keep  the  program 
on  schedule  once  it's  back  on  track. 

Why  do  Program  Managers  (PMs)  sched¬ 
ule?  The  simple  answer  is  they  need  a  road 
map  for  all  program  players.  In  reality, 
scheduling  can  accomplish  far  more  than 
providing  a  list  of  activities  and  times. 


Effective  scheduling  supports  the  follow¬ 
ing  key  program  management  activities: 

•  Provides  the  basis  for  effective  com¬ 
munications  within  the  government  team 
and  with  contractors, 

•  Identifies  a  baseline  for  program  status 
monitoring,  reporting,  and  program  control, 

•  Facilitates  management,  and 

•  Provides  the  basis  for  resource  analysis 
and  leveling,  exploration  of  alternatives, 
and  cost/time  tradeoff  studies. 

On  the  other  hand,  poor  scheduling  can 
adversely  impact  a  program  in  a  number 
of  areas.  Haphazard  schedules  make  it 
difficult,  at  best,  to  determine  a  realistic 
completion  date  and  to  efficiently  allocate 
resources  to  the  entire  program.  This  cre¬ 
ates  financial  problems — escalation  of 
costs,  increased  support  costs,  delayed 
return  on  investment,  funding  cuts,  or 
program  termination. 

Since  scheduling  is  a  powerful  planning, 
control,  and  communications  tool  avail¬ 
able  for  program  management,  PMs  must 
have  a  good  working  knowledge  of  sched¬ 
uling  practices  and  applications  (such  as 
Gantt,  milestone,  and  network  schedules) 
in  order  to  achieve  program  goals.  PMs 
will  not  always  have  to  construct  detailed 
schedules,  but  they  must  be  able  to  under¬ 
stand  and  analyze  schedules  created  by 
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others  (e.g.,  contractors)  to  successfully 
manage  a  program.  Since  scheduling  is  an 
intrinsic  and  indispensable  element  of  the 
management  process,  it  is  treated  within 
the  context  of  program  management. 

1.2  PURPOSE  OF  THIS  GUIDE 

This  guide  is  an  introduction  to  sched¬ 
uling.  It  is  meant  for  people  who  already 
have  some  experience  in  program  man¬ 
agement  and  those  who  seek  to  learn  more 
about  the  subject.  It  is  not  a  detailed 
treatment  of  the  subject,  but  instead,  ex¬ 
plains  how  scheduling  fits  into  the  overall 
program  management  effort  and  how  to 
accomplish  schedule  planning.  It  also  il¬ 
lustrates  different  scheduling  concepts  and 
techniques  and  how  they  can  be  applied 
and  analyzed  to  manage  effectively.  Fi¬ 
nally,  it  is  intended  as  a  road  map  to  other 
useful  and  more  comprehensive  docu¬ 
ments  and  texts  on  the  subjects  of  project 
management,  planning,  and  scheduling 
that  are  available  in  the  literature. 

1.3  GUIDE  CONTENT 

In  order  to  provide  a  suitable  context  for 
the  topic  of  scheduling.  Chapter  2  provides 
an  overview  of  both  program  management 
and  the  acquisition  process  and  the  role 
scheduling  plays  in  each. 

Chapter  3  expands  on  the  role  of  schedul¬ 
ing  in  program  management  and  addresses 
the  following  topics:  work  breakdown 
structure,  integrated  master  plans  and 
schedules,  and  earned  value  management. 
It  concludes  with  a  discussion  of  schedule 
preparation  and  schedule  risk. 

Chapter  4  introduces  the  topic  of  schedul¬ 
ing  techniques  with  a  general  discussion  of 


the  various  types  of  schedules  and  how 
and  why  they  evolved.  This  chapter  is  a 
precursor  for  Chapters  5, 6,  and  7,  which 
present  a  more  detailed  discussion  of 
the  key  schedule  types.  These  chapters 
focus  on  Gantt  and  milestone  schedules, 
network  schedules,  and  production 
schedules. 

Chapter  8  introduces  the  concept  of  time 
management  as  it  relates  to  the  program 
and  to  the  PM.  Chapter  9  presents  the 
subject  of  automated  project  planning  tools 
and  summarizes  some  of  the  desirable  fea¬ 
tures  of  currently  available  software  prod¬ 
ucts.  In  addition  to  an  overview  describing 
the  types  of  automated  tools  available,  this 
chapter  provides  some  suggestions  on  how 
to  find  and  evaluate  the  latest  products. 
The  chapter  concludes  with  a  summary  of 
information  sources  that  will  be  useful  for 
further  inquiry. 

1.4  OTHER  SOURCES  OF  DATA 

As  previously  noted,  this  guide  is  intended 
as  a  primer.  There  is  a  considerable  body  of 
literature  on  the  subject  of  scheduling.  Much 
of  it  is  of  an  academic  nature  not  specifi¬ 
cally  keyed  to  defense  acquisition.  A  num¬ 
ber  of  these  texts  are  listed  in  the  Bibliogra¬ 
phy  Appendix  of  this  guide.  Additionally, 
an  enormous  amount  of  relevant  informa¬ 
tion  can  be  secured  by  searching  the  web 
using  some  of  the  popular  search  engines. 
Of  particular  use  to  PMs  is  the  Defense 
Acquisition  Deskbook,  available  on  the 
Internet  (http:  /  /  www.deskbook. osd.mil). 
The  Deskbook  includes  a  database  contain¬ 
ing  mandatory  and  discretionary  policy 
documents.  Department  of  Defense  and 
component  discretionary  practices,  soft¬ 
ware  tools  and  descriptions,  front-line  wis¬ 
dom  and  advice,  and  sample  formats. 
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PROGRAM  MANAGEMENT  AND 
THE  ACQUISITION  PROCESS 


2.1  PROGRAM  MANAGEMENT 
OVERVIEW 

The  Department  of  Defense  (DoD)  consid¬ 
ers  program  management  to  consist  of  the 
tasks  and  activities  that  must  be  done  in 
order  to  design,  develop,  field,  and  sup¬ 
port  a  weapons  system.  DoD  directives 
describe  an  Acquisition  Program  as:  "A 
directed,  funded  effort  that  is  designed  to 
provide  a  new,  improved,  or  continuing 
weapons  system  or  automated  informa¬ 
tion  system  (AIS)  capability  in  response  to 
a  validated  operational  need."1  DoD  con¬ 
siders  the  "program"  to  include  the  ele¬ 
ments  of  the  acquisition  process,  such  as 
the  planning,  programming,  and  budget¬ 
ing  process,  and  the  design,  development, 
and  production  of  the  system.  Practically 
speaking,  a  DoD  program  consists  of  a 
combination  of  organizational  resources, 
assembled  to  create  a  weapons  system  to 
meet  a  specific  operational  requirement. 

Four  key  considerations  typically  involved 
in  a  program  are: 

•  Cost  to  produce  the  system, 

•  Time  required  to  complete  the  effort, 

•  Capability/technical  performance  re¬ 
quired  to  meet  needs,  and 

•  Contribution  of  the  system  to  the  over¬ 
all  defense  operational  and  strategic  plans. 


For  purposes  of  this  guidebook.  Program 
Management  consists  of  the  planning,  or¬ 
ganizing,  staffing,  controlling,  and  leading 
(POSCL)  management  functions.  Other 
functions  sometimes  included  in  a  pro¬ 
gram  management  context  are  scheduling, 
budgeting,  monitoring,  directing,  and 
maintaining  consensus  and  support.  For 
this  guidebook,  these  latter  functions  are 
considered  subcategories  of  the  basic  five 
functions,  when  appropriate. 

•  Planning  addresses  the  program  mis¬ 
sion,  objectives,  goals,  and  strategy  and 
includes  all  management  activities  that  re¬ 
sult  in  selection  of  a  course  of  action. 

•  Organizing  considers  the  resources  in¬ 
volved  and  how  are  they  related.  This  func¬ 
tion  addresses  the  alignment  of  people, 
funds,  equipment,  facilities,  etc.,  and  the 
structure  of  the  organization  in  order  to 
meet  program  goals;  it  identifies: 

-  Authority — The  power  to  make  final 
decisions 

-  Responsibility — The  obligation  to  per¬ 
form  assignments 

-  Accountability— The  state  of  being 
answerable  for  the  completion  of  an 
assignment. 
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•  Staffing  addresses  the  qualifications 
and  special  skills  that  may  be  required 


for  persons  assigned  to  each  position  in 
the  program  and  the  time  phasing  of  as¬ 
signments. 

•  Controllingis  the  function  during  which 
the  manager  monitors,  measures,  evalu¬ 
ates,  and  corrects  program  activities  to  en¬ 
sure  that  actual  operations  conform  to 
plans. 

•  Leading  is  the  process  whereby  one 
individual  exerts  his/her  influence  over 
others  in  a  group.  Directing,  an  element  of 
leadership,  is  the  process  of  implement¬ 
ing,  through  the  talents  of  others,  the  plans 
to  meet  program  objectives.  This  includes 
training,  supervising,  delegating,  motivat¬ 
ing,  counseling,  and  coordinating. 

In  a  broad  sense,  the  planning  phase  in¬ 
cludes  the  tasks  associated  with  defining 
the  work  requirements,  specifying  the  quan¬ 
tity  and  quality  of  work,  identifying  re¬ 
sources,  and  organizing  them  to  best  carry 
out  the  program.  Likewise,  the  manage¬ 
ment  or  execution  phase  includes  the  tasks  of 
monitoring  progress,  comparing  actual  to 
predicted  outcomes,  analyzing  the  impact 
of  differences  between  planned  and  actual 
achievements,  and  adjusting  the  program 
as  necessary. 

2.2  THE  EVOLUTION  OF 

PROGRAM  MANAGEMENT 

Formal  program  management  came  to  the 
forefront  in  the  late  1950s.  The  need  to 
develop  and  implement  a  management 
approach  to  manage  large-scale  military 
systems,  both  weapons  and  support  sys¬ 
tems,  stimulated  the  government  and  aero¬ 
space  industry  to  devise  the  means  to  plan 
and  execute  complex  programs.  As  the 
cost  of  weapons  systems  increased  and  the 
intensity  of  the  Cold  War  grew,  DoD  also 


felt  the  need  to  predict  the  cost,  schedule, 
and  performance  of  its  new  systems.  Mili¬ 
tary  organizations  (predecessors  of  cur¬ 
rent  "acquisition"  organizations),  in  conjunc¬ 
tion  with  defense  contractors,  developed 
much  of  the  early  theory  and  practices  of 
program  management  as  new  technolo¬ 
gies  emerged. 

The  use  of  "task  teams"  or  program  teams 
and  other  organizational  entities  led  to  the 
emergence  of  a  program  management  phi¬ 
losophy  for  integrating  activity  in  organiza¬ 
tions.  As  the  program  management  disci¬ 
pline  evolved,  organizations  developed 
special  techniques  for  planning,  organiz¬ 
ing,  staffing,  controlling,  and  leading  pro¬ 
grams  to  integrate  those  activities  from  a 
focal  point  in  the  organizational  structure. 
Moreover,  program  management  ad¬ 
dressed  the  elements  of  technical  perfor¬ 
mance,  cost,  and  schedule  on  a  continual 
rather  than  one-time  basis  in  the  evolution 
of  a  program  and  considered  them  within 
the  context  of  an  organization's  operational 
(short-term)  and  strategic  (long-term) 
objectives. 

DoD  has  recently  improved  management 
with  the  introduction  of  the  concept  of 
Integrated  Product  and  Process  Develop¬ 
ment  (IPPD)  and  Integrated  Product  Teams 
(IPTs).  IPPD  integrates  all  acquisition  ac¬ 
tivities  to  optimize  system  development, 
production,  and  deployment.  Key  to  the 
success  of  this  concept  are  the  IPTs,  com¬ 
posed  of  qualified  and  empowered  repre¬ 
sentatives  from  all  appropriate  functional 
disciplines  who  work  together  to  identify 
and  resolve  issues.  IPTs  are  the  founda¬ 
tion  for  program  management.  One  of  the 
tenets  of  IPPD  is  the  use  of  event-driven 
scheduling,  which  relates  program  events 
to  their  accomplishment  and  accomplish¬ 
ment  criteria.  Its  use  reduces  risk  by 
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ensuring  that  product  and  process  matu¬ 
rity  is  incrementally  demonstrated  prior  to 
beginning  follow-on  activities. 

2.3  THE  ACQUISITION  PROCESS 
AND  SCHEDULING 

For  the  management  of  programs,  the  DoD 
acquisition  process  provides  a  framework 
that  consists  of  a  series  of  phases  and  mile¬ 
stones.  The  phases  are  a  logical  means  of 
progressively  translating  broad  mission 
need  statements  into  well-defined  system- 
specific  requirements  and  ultimately  into 
operationally  effective,  suitable,  and  sur- 
vivable  systems.  Each  phase  is  designed, 
among  other  things,  to  manage/ reduce  the 
risks,  ensure  affordability,  and  deliver  the 
system  to  the  user  as  soon  as  possible. 
Milestones  are  the  points  in  time  where 
decision  makers  evaluate  the  status  of  the 
program  and  determine  if  the  program 
should  proceed  to  the  next  phase.  Prudent 
consideration  of  schedule  implications  is 
important  in  all  phases  of  a  program. 

Milestone  Decision  Authority  (MDA)  and 
Service  acquisition  officials  are  encouraged 
to  tailor  programs  to  eliminate  phases  or 
activities  that  result  in  little  payoff  in  terms 
of  fielding  time  or  cost.  To  effectively 
tailor  a  program,  managers  must  under¬ 
stand  scheduling,  resource  availability  and 
allocation,  and  the  risk  associated  with  the 
tailoring. 

An  acquisition  strategy  defines  the  busi¬ 
ness  and  technical  management  approach 
to  meet  objectives  within  schedule  and 
program  constraints.  A  primary  goal  is  to 
minimize  the  time  and  cost  of  satisfying  a 
valid  need,  consistent  with  common  sense 
and  sound  business  practices.  A  PM  pre¬ 
pares  a  preliminary  acquisition  strategy  at 
Milestone  0  and  updates  the  strategy  to 


support  each  milestone  decision  by  de¬ 
scribing  activities  and  events  planned  for 
the  upcoming  phase  and  relating  the  ac¬ 
complishments  of  that  phase  to  the 
program's  overall,  long-term  objectives. 
The  acquisition  strategy  is  first  formally 
approved  and  published  at  MSI,  Program 
Initiation.  It  provides  a  master  schedule  for 
research,  development,  test,  production, 
fielding,  and  other  activities  essential  to 
program  success.  This  master  schedule 
also  serves  as  the  basis  for  formulating 
functional  plans  and  schedules. 

As  a  program  evolves  through  subsequent 
phases,  new  information  becomes  avail¬ 
able  that  permits  refinement  of  schedules 
and  assignment  of  resources.  Understand¬ 
ing  of  program  risk  becomes  more  specific 
as  the  system  under  development  is  de¬ 
fined,  thereby  allowing  identification  of 
risk-handling  initiatives  and  their  effect  on 
schedule.  Schedule  considerations  are  an 
integral  part  of  any  Source  Selection  pro¬ 
cess,  from  preparation  of  the  Request  for 
Proposal  (RFP)  through  proposal  evalua¬ 
tion.  After  contract  award,  the  schedule 
serves  as  a  basis  to  determine  progress  and 
assess  the  need  for  management  action. 

Government  developers  should  design  their 
contracts  with  industry  to  allow  time  for 
milestone  decisions,  permit  demonstration 
of  exit  criteria  in  time  to  support  milestone 
reviews  and  to  reflect  expenditure  of  money 
with  the  program's  funding  profile.  A  good 
acquisition  strategy  allows  fiscal  control 
without  delaying  the  acquisition  decisions 
or  contracts  while  adequately  considering 
risk.  In  other  words,  it  reflects  thoughtful 
schedule  and  resource  planning. 

As  a  key  element  of  the  planning  proess,  PMs 
must  update  the  schedule  as  more  is  learned 
about  the  program  and  as  changes  occur. 
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With  each  new  update,  program  cost,  time, 
and  requirements  may  change.  PMs  must 
respond  by  changing  the  mix  and  level  of 
resources  and  continuously  updating  the 
program  plan  and  the  schedule  as  needed. 

2.4  RISK  MANAGEMENT  AND 
SCHEDULING 

DoD  defines  risk  management  as  "the  act 
or  practice  of  controlling  risk.  It  includes 
risk  planning,  assessing  risk  areas,  devel¬ 
oping  risk-handling  options,  monitoring 
risks  to  determine  how  risks  have  changed, 
and  documenting  the  overall  risk  manage¬ 
ment  program."2  As  part  of  their  responsi¬ 
bility  to  manage  risk,  PMs  must  consider 
risk  in  their  planning  and  scheduling  prac¬ 
tices.  Risk  management  is  concerned  with 
the  identification  of  uncertainties  that 
threaten  cost,  schedule,  and  performance 
objectives,  and  the  development  and  imple¬ 
mentation  of  actions  to  best  deal  with  those 
uncertainties. 


Risk  management  and  scheduling  are 
closely  tied.  Consideration  of  one  requires 
a  reassessment  of  the  other.  For  example, 
in  creating  the  strategy  and  plans  to  handle 
program  risk,  a  PM  must  con¬ 
sider  how  the  approach  affects  the  pro¬ 
gram  schedule.  Similarly,  any  tradeoffs 
between  cost  and  performance  must  take 
into  account  schedule  implications.  Con¬ 
versely,  any  change  to  the  program  sched¬ 
ule  must  consider  the  impact  on  the  overall 
program  objectives  and  on  cost  and  perfor¬ 
mance.  The  challenge  is  to  develop  a  plan 
that  balances  risk,  cost,  schedule,  and  per¬ 
formance. 

Schedule  risk  is  defined  as  the  likelihood 
and  consequences  of  failing  to  meet  the 
program  schedule,  and  it  is  an  integral  part 
of  program  risk.  This  topic  is  covered  in 
Chapter  3. 


ENDNOTES 


1  DoDD  5000.1,  Defense  Acquisition,  March  15, 1996.  (Being  revised  and  updated  as  of  1  January  2000) 

2  Ibid. 
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3 

PROGRAM  MANAGEMENT  AND  SCHEDULING 


As  discussed  in  the  previous  chapters, 
scheduling  is  one  of  the  most  powerful 
tools  available  to  the  PM,  and  its  effective 
application  is  essential  to  program  suc¬ 
cess.  While  it  is  a  key  element  in  perform¬ 
ing  all  program  management  functions,  it 
is  also  critical  to  the  accomplishment  of 
planning  and  controlling  management 
functions.  This  chapter  discusses  schedul¬ 
ing  in  the  context  of  these  two  functions 
and  addresses  the  essential  elements  and 
considerations  in  schedule  planning. 

3.1  PROGRAM  PLANNING  AND 
SCHEDULING 

Program  planning  is  the  process  of  deter¬ 
mining  what  needs  to  be  accomplished,  by 
whom,  when,  and  under  what  resource 
constraints.  It  is  arguably  the  most  impor¬ 
tant  of  the  program  management  functions. 
Without  a  sound  and  comprehensive  plan, 
it  is  virtually  impossible  to  develop  a  mean¬ 
ingful  budget,  effectively  organize  and  staff 
the  program  office,  direct  the  actions  of  the 
program  office,  or  monitor  and  control  the 
program.  In  addition  to  determining  the 
"what,  where,  who,  with  what,  and  when" 
of  a  program,  planning  also  helps  to  iden¬ 
tify  risk  areas  and  ways  to  handle  the  risk, 
and  establishes  the  program  baselines. 

There  are  a  number  of  products  of  the 
planning  process.  Among  them  are: 

•  Acquisition  Strategy — This  is  the  com¬ 
prehensive,  integrated  plan  the  program 
will  follow.  It  provides  an  overall  concept 


of  the  program  that  functional  plans  will 
lay  out  in  greater  detail  and  reflects  the 
strategy  that  will  be  followed  to  meet  pro¬ 
gram  objectives  and  to  handle  risk  in  the 
program.  The  acquisition  strategy  in¬ 
cludes  a  program  structure/ schedule 
which  depicts  a  visual  overview  and  pic¬ 
ture  presentation  of  the  acquisition  strat¬ 
egy.  This  schedule  is  a  single  diagram 
similar  to  the  diagram  shown  in  Figure  3-3, 
and  defines  the  relationship  among  acqui¬ 
sition  phases,  decision  milestones,  solici¬ 
tations,  contract  awards,  systems  engineer¬ 
ing  design  reviews,  contract  deliveries,  test 
and  evaluation  activities,  production  re¬ 
leases,  and  operational  deployment  objec¬ 
tives.  It  includes  quantities  to  be  procured 
and  delivered  by  fiscal  year  by  phase  in 
terms  of  prototypes,  engineering 
developmemt  models,  low-rate  intitial  pro¬ 
duction  and  full-rate  production.  The  pro¬ 
gram  structure/schedule  is  a  key  decision 
review/milestone  document;  it  summa¬ 
rizes  the  program  and  is  built  from  many 
other  more  detailed  schedules  found  in 
functional  plans  such  as  test  and  evalua¬ 
tion,  contracting,  etc.  It  is  sometimes  re¬ 
ferred  to  as  the  Master  Program  Schedule 
(MPS).  In  addition  to  this  top  level  struc¬ 
ture/schedule,  the  PM  may  deem  it  neces¬ 
sary  to  have  more  detailed  program  man¬ 
agement  Integrated  Master  Plans  (IMP )  and 
Integrated  Master  Schedules  (IMS)  pre¬ 
pared  and  submitted  by  the  contractor 
during  the  proposal  process.  See  the  DSMC 
Acquisition  Strategy  Guide1  for  information 
on  structuring,  developing,  and  executing 
an  acquisition  strategy. 
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•  Functional  Plans — These  are  the  de¬ 
tailed  plans  that  lay  out  the  approach  to 
be  taken  in  the  different  functional  areas. 
Examples  include:  the  Test  and  Evalua¬ 
tion  Master  Plan  (TEMP)  and  Command, 
Control,  Communications,  Computers,  and 
Intelligence  (C4I)  Support  Plan,  which  are 
required;  and  the  Systems  Engineering 
Master  Plan  (SEMP),  Logistics  Support 
Plan  (LSP),  etc.,  which  are  optional. 

•  Work  Breakdown  Structure  (WBS) — 

The  WBS  provides  a  basic  framework  for 
identifying  each  element  of  a  project  in 
increasing  levels  of  detail.  In  essence,  it 
describes  the  way  work  is  performed.  The 
WBS  also  provides  a  coherent  method  for 
reporting  progress  toward  plan  goals. 

•  Integrated  Master  Plan  (IMP) — The 

IMP  is  an  event-based  plan  depicting  the 
overall  structure  of  the  program  and  the 
key  processes,  activities,  and  milestones. 
It  defines  accomplishments  and  criteria  for 
each  event. 

•  Integrated  Master  Schedule  (IMS) — 

The  IMS  shows  the  detailed  tasks  and 
timing  for  events  in  the  IMP  and  depicts 
the  logical  progression  of  events  through¬ 
out  the  program.  These  tasks  should  be 
directly  traceable  to  the  IMP  and  the  WBS. 

•  Schedules — A  series  of  schedules  are 
developed  during  the  planning  process, 
all  of  which  are  derived  from  the  IMS. 
These  schedules  are  developed  to  show 
the  details  required  to  complete  key  activi¬ 
ties  and  milestones. 

•  Budget — The  budget  reflects  the  cost 
of  the  integration  of  the  scope,  schedule, 
and  resource  plan  for  accomplishing  the 
work. 


Scheduling  is  a  critical  element  in  the  plan¬ 
ning  process.  In  addition  to  being  an  out¬ 
put  of  the  process  as  discussed  above,  it 
also  contributes  to  the  development  of  the 
other  outputs.  The  early  involvement  of 
people  who  are  knowledgeable  and  experi¬ 
enced  in  scheduling  techniques  can  contrib¬ 
ute  to  the  effective  translation  of  strategic 
concepts  and  ideas  into  detailed  logic  dia¬ 
grams,  depicting  the  program  activities 
and  relationships  among  activities.  This 
can  be  very  useful  in  developing  budget 
and  detailed  functional  plans,  especially 
in  identifying  the  required  resources  and 
leveling  them  throughout  the  activities. 

The  WBS  and  the  IMP/ IMS  are  important 
concepts  used  in  the  scheduling  process 
and  are  described  in  more  detail  in  the 
following  sections. 

3.2  WORK  BREAKDOWN  STRUCTURE 

During  the  1960s,  the  impetus  to  develop  a 
tool  to  help  project  managers  define  a 
project  in  a  cohesive  way  gave  rise  to  the 
development  of  the  WBS.  WBS  use  has  not 
been  confined  to  the  DoD  and  its  contrac¬ 
tors;  rather,  it  is  now  used  in  many  com¬ 
mercial  enterprises.  Several  years  after  the 
emergence  of  the  WBS  concept,  DoD  pub¬ 
lished  a  WBS  standard  for  DoD  acquisition 
organizations  as  well  as  their  contractors  to 
use:  MIL-STD-881B.  This  standard  has 
been  superseded  by  a  handbook,  MIL- 
HDBK-881,  dated  2  January  1998.  It  con¬ 
tains  much  of  the  same  information  as  its 
predecessor  but  is  not  directive  in  nature 
and  is  for  guidance  only. 

MIL-HDBK-881defines  a  WBS  as: 

•  A  product-oriented  family  tree  com¬ 
posed  of  hardware,  software,  services,  data. 
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Figure  3-1.  Generic  Aircraft  System  Program  WBS 


and  facilities.  The  family  tree  results  from  needs  to  go  unless  the  items  identified  are 
systems  engineering  efforts  during  the  ac-  high  cost  or  high  risk.  In  that  case,  the  WBS 
quisition  of  a  defense  materiel  item.  should  be  taken  to  a  lower  level  of 

definition. 

•  A  WBS  displays  and  defines  the  prod¬ 
uct,  or  products,  to  be  developed  and/or  WBS's  apply  to  seven  specific  categories  of 

produced.  It  relates  the  elements  fo  work  defense  materiel  systems:  aircraft;  elec- 

to  be  accoomplished  to  each  other  and  to  tronic/ automated  software;  missile,  ord- 

the  end  product.  nance;  ship;  space;  and  surface  vehicle. 

The  WBS  should  be  developed  and  main- 

•  A  WBS  can  be  expressed  down  to  any  tained  based  on  the  systems  engineering 

level  of  interest.  However,  the  top  three  efforts  throughout  the  system's  life  cycle, 

levels  are  as  far  as  any  program  or  contract 


9 


SOW  Task 


Requirement 

WBS  Elements 

Integrated  Master  Schedule 


1 


19XX 

19XY 

19XZ 

Program  Events 

PDR 

CDR 

Detailed  Tasks 

1.  Preliminary  Design  Complete 

2.  Duty  Cycle  Defined 

Zv 

_ 1 

zs. 

Figure  3-2.  IMP/IMS  Sample 


Figure  3-1  is  an  example  of  a  level  3  program 
WBS  for  an  aircraft  system.  The  WBS  ap¬ 
proach  provides  a  powerful  technique  for 
scoping  a  project  in  a  manner  that  provides 
management  with  insight  into  project  re¬ 
quirements  and  performance — from  the 
very  top,  or  systems  level,  to  the  lowest 
level  of  definition  of  a  work  product.  Plan¬ 
ning  work  using  the  WBS  approach  serves 
as  the  basis  for  both  estimating  and  sched¬ 
uling  resource  requirement. 

3.2.1  Integrated  Master  Plans/ 
Schedules 

The  IMP  is  a  very  effective  tool  of  program 
management.  It  is  the  contractor's  event- 
based  plan  for  accomplishing  the  State¬ 
ment  of  Objectives  (SOO)  and  Statement  of 
Work  (SOW).  It  identifies  the  key  activi¬ 
ties,  events,  milestones,  and  reviews  that 
make  up  the  program.  A  program  IMP  is 


prepared  initially  by  the  contractor  and 
provides  the  basis  for  development  of  sub¬ 
ordinate  IMPs  and  other  functional  plans. 
It  also  identifies  those  events  and  activities 
that  will  be  included  in  the  IMS. 

The  IMS  is  a  networked  multi-layered 
schedule  generated  by  the  contractor  that 
begins  with  all  identified  IMP  events,  ac¬ 
complishments,  and  criteria.  It  shows  the 
expected  start  and  finish  dates  of  these 
events.  It  contains  all  contractually  re¬ 
quired  events/  milestones  such  as  reviews, 
tests,  completion  dates,  and  deliveries 
specified  in  the  program  WBS. 

The  IMP  is  prepared  by  the  contractor  dur¬ 
ing  the  proposal  process.  It  is  maintained 
by  the  government  program  office  and  con¬ 
tractor  through  a  collaborative  effort  in¬ 
volving  all  the  program  "stakeholders."  In 
some  cases,  a  preliminary  IMP  may  be 
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developed  by  the  government,  with  indus¬ 
try  input,  during  pre-solicitation.  The  IMP 
defines  contract  requirements  stated  in  the 
RFP  and  contractors  use  it  to  develop  the 
IMS  and  detailed  functional  schedules. 
These  integrated  schedules  tie  together  all 
program  tasks  by  showing  their  logical 
relationships  and  any  constraints  control¬ 
ling  the  start  or  finish  of  each  task.  This 
process  results  in  a  hierarchy  of  related 
functional  and  layered  schedules  derived 
from  the  WBS  that  can  be  used  for  monitor¬ 
ing  and  controlling  program  progress.  An 
example  (suggested  format)  of  an  IMP/ 
IMS  for  an  aircraft  development  program 
is  depicted  in  Figure  3-2.  The  IMS  should 
be  expanded  down  to  the  level  of  detail 
appropriate  for  the  scope  and  risk  of  the 
program.  Programs  with  high  risk  should 
show  more  detail  in  the  IMS  to  provide  the 
visibility  necessary  to  manage  risk.  A  more 
detailed  discussion  of  IMS's  is  contained  in 
Appendix  A.  A  Data  Item  Decription  (DID) 
has  been  developed  by  the  Department  of 
Defense  for  the  IMS;  the  identification  num¬ 
ber  is  DI-MISC-81 183A.  This  DID  is  at  Tab  1 
to  Appendix  A. 

3.3  PROGRAM  CONTROLLING 
AND  SCHEDULING 

The  controlling  function  contains  all  those 
activities  that  a  program  manager  under¬ 
takes  in  attempting  to  ensure  that  the  ac¬ 
tual  program  conforms  to  the  developed 
plan,  to  include  the  implementation  of  nec¬ 
essary  action  to  get  the  program  back  on 
the  plan  if  possible.  To  control  a  program, 
the  PM  needs  the  means  to  monitor  pro¬ 
gram  progress  against  the  established  plan, 
or  the  program  baseline.  In  its  simplest 
form,  the  program  schedule  can  serve  as  a 
baseline  against  which  to  measure  progress. 
If  there  are  indications  that  an  activity  is 
falling  behind  schedule,  this  information 


can  be  used  by  the  manager  as  a  basis  for 
corrective  action.  However,  considering 
schedule  information  alone  can  be  mis¬ 
leading.  Successful  management  requires 
the  integration  of  the  technical,  schedule, 
and  cost  aspects  of  a  program.  Thus,  some 
form  of  integrated  performance  measure¬ 
ment  is  needed  for  monitoring  and  control¬ 
ling  a  program.  The  concept  of  earned  value 
management  provides  such  a  capability. 

3.3.1  Earned  Value  Mangement 

Earned  Value  Management  (EVM)  is  the 
use  of  an  integrated  management  system 
that  coordinates  work  scope,  schedule,  and 
cost  goals  and  objectively  measures  pro¬ 
gress  toward  these  goals.2  The  purpose  of 
EVM  is  to  provide  contractor  and  gov¬ 
ernment  PMs  with  accurate  data  to  moni¬ 
tor  program  execution.  It  is  also  intended 
to  provide  an  adequate  basis  for  sound 
contractor  and  government  decision  mak¬ 
ing  by  requiring  that  the  contractor's  inter¬ 
nal  management  control  systems  produce 
data  that:  (1)  indicate  work  progress;  (2) 
properly  relate  cost,  schedule,  and  techni¬ 
cal  accomplishments;  (3)  are  valid,  timely, 
and  able  to  be  audited;  and  (4)  provide 
DoD  component  managers  with  informa¬ 
tion  at  a  practical  level  of  summarization. 

The  DoD  earned  value  process  holds  the 
contractor  responsible  for  effective  imple¬ 
mentation  of  an  EVM  system.  DoD  does  not 
prescribe  a  specific  EVM  system  for  con¬ 
tractors  to  use;  instead,  it  has  established  a 
set  of  criteria  that  the  contractors'  systems 
must  meet  to  be  acceptable.  The  require¬ 
ment  to  use  an  EVM  system  that  meets  the 
criteria  is  dependent  on  the  type  and  size 
of  the  contract.  DoD  Regulation  5000.2-R 
defines  the  contracts  that  must  use  such  an 
EVM  system  as  well  as  the  criteria  for  an 
acceptable  system.  For  contracts  that  do 
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not  meet  these  thresholds,  contractor  man¬ 
agement  information  is  provided  to  the 
government  using  a  Cost /Schedule  Status 
Report  (C/SSR).  This  report  should  be 
based  on  an  underlying  management  sys¬ 
tem  that  uses  an  earned  value  approach  for 
tracking  progress.  Such  a  system  does  not 
have  to  meet  the  EVM  criteria  of  DoD 
5000.2-R;  however,  the  government  should 
negotiate  with  the  contractor  to  ensure  that 
the  system  does  emphasize  earned  value 
methodology. 

Basically,  earned  value  relates  resource 
planning  to  schedules  and  to  technical  per¬ 
formance  requirements.  All  work  (identi¬ 
fied  in  the  Program  and  Contract  Work 
Breakdown  Structures)  is  planned,  bud¬ 
geted,  and  scheduled  in  time-phased 
"planned  value"  increments  constituting  a 
performance  measurement  baseline.  As 
work  is  performed,  it  is  "earned"  on  the 
same  basis  as  it  was  planned,  e.g.,  in  bud¬ 
geted  dollars  or  labor-hours.  Planned  value 
[budgeted  cost  of  work  scheduled  (BCWS)] 
compared  with  earned  value  [budgeted  cost 
of  work  performed  (BCWP)]  measures  the 
dollar  volume  of  work  planned  versus  the 
equivalent  dollar  value  of  work  accom¬ 
plished.  The  difference,  if  any,  is  termed 
the  "schedule"  or  "accomplishment"  vari¬ 
ance.  Earned  value  (BCWP)  compared 
with  the  actual  cost  of  the  work  performed 
(ACWP)  provides  an  objective  measure¬ 
ment  of  cost  performance.  Any  difference 
is  called  the  cost  variance. 

The  three  data  points — BCWS,  BCWP,  and 
ACWP — are  outputs  of  the  EVM  system  and 
are  provided  to  the  government  ona  monthly 
basis.  They,  along  with  the  schedule  and  cost 
variances,  provide  the  basic  information 
needed  to  determine  program  status  at  a 
given  time,  and  to  identify  the  elements  that 
are  driving  each  of  the  variances. 


Analysis  of  these  data  points  over  time 
also  identifies  trends  that  may  affect  or 
impact  the  future  performance  for  the  re¬ 
mainder  of  the  contract.  This  is  important; 
it  enables  PMs  to  isolate  causes  of  recur¬ 
ring  variations  and  to  take  alternative  ac¬ 
tions  that  will  improve  performance.  Quan¬ 
titative  techniques  can  also  be  applied  to 
EVM  data  to  predict  program  performance 
at  completion  in  terms  of  cost  and  sched¬ 
ule.  The  DSMC  EVM  Textbook3  provides 
detailed  information  on  the  application  of 
EVM  techniques. 

Success  of  EVM  techniques  is  dependent  on 
several  things,  not  the  least  of  which  is 
effective  and  accurate  contractor  schedul¬ 
ing.  EVM  system  criteria  do  not  require 
contractors  to  use  specific  scheduling  tech¬ 
niques.  However,  they  do  seek  formality, 
consistency,  and  discipline  throughout  the 
scheduling  process.  The  contractor's  sched¬ 
uling  system: 

•  Provides  a  summary  or  master  sched¬ 
ule  and  related  subordinate  schedules 
showing  vertical  traceability  from  the  mas¬ 
ter  to  the  detailed  schedules 

•  Identifies  key  milestones  and  activities 
and  indicates  significant  constraints  and 
relationships 

•  Provides  current  status  and  forecast  of 
completion  dates  of  scheduled  work  that 
enable  comparison  of  planned  and  actual 
status  of  program  accomplishments 

•  Establishes  a  schedule  baseline 

•  Provides  horizontal  traceability  show¬ 
ing  interrelationships  among  various  ac¬ 
tivities. 
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The  scheduling  baseline  usually  consists 
of  a  hierarchy  of  vertically  integrated 
schedules,  with  each  lower-level  sched¬ 
ule  more  fully  identifying  and  expanding 
the  tasks  necessary  to  meet  the  program's 
objectives.  Generally,  three  sets  of  sched¬ 
ules  are  prepared: 

•  Master  Schedule  (MS) — The  top-level 
schedule  that  summarizes  key  program 
activities  and  milestones  and  depicts  the 
logical  progression  of  events  throughout  a 
contract.  Program  Structures /Master  Pro¬ 
gram  Schedules  developed  by  the  govern¬ 
ment  PM  reflect  information  contained  in 
the  contractor's  Master  Schedule. 

•  Intermediate  Schedules — The  sched¬ 
ule  that  ties  the  MS  to  the  detailed  sched¬ 
ules.  It  allows  for  rollup  of  detailed  sched¬ 
ules  to  summary  levels  that  are  useful  for 
management. 

•  Detailed  Schedules — The  schedules  at 
the  control  account  or  work  package  level. 
Work  packages  must  be  distinguishable 
from  each  other  and  must  include  definite 
start  and  completion  dates.  They  are  pre¬ 
pared  by  the  contractor  with  government 
concurrence. 

3.4  SCHEDULE  PREPARATION 

As  stated  earlier,  scheduling  is  a  critical 
element  of  the  planning  process.  Con¬ 
versely,  planning  is  critical  to  the  devel¬ 
opment  of  effective  schedules.  Near-term 
scheduling  can  and  should  be  accom¬ 
plished  in  sufficient  detail  to  support 
management  at  each  level.  Far-term,  or 
rolling-wave,  scheduling  will  be  less  pre¬ 
cise,  accounting  for  the  alternative  paths 
that  the  program  may  take.  As  the  pro¬ 
gram  approaches  each  phase,  the  sched¬ 
ule  for  that  phase  will  be  fleshed  out  with 


more  detailed  schedule  information.  The 
schedule  for  the  out-year  phases  will  be 
adjusted  based  on  the  most  current  infor¬ 
mation.  However,  this  should  not  be  taken 
as  a  license  to  make  easy  changes  in  the 
schedule.  Every  effort  should  be  made  to 
maintain  the  original  schedule. 

In  all  programs,  there  will  always  be  a 
requirement  to  make  tradeoffs  between 
cost,  schedule,  and  performance.  Cost  in¬ 
cludes  all  resources — people,  money, 
equipment  and  facilities.  Performance  in¬ 
cludes  quality  and  supportability  param¬ 
eters.  The  best  schedule  supports  the  best 
tradeoff  between  these  competing  de¬ 
mands,  taking  into  account  the  risks  that 
are  associated  with  each  tradeoff  and  the 
impact  on  the  overall  program. 

The  preparation  of  program  schedules 
should  be  done  within  a  formal  structure. 
The  procedures  to  be  followed  should  be 
specified,  to  include  such  things  as  soft¬ 
ware  applications  to  be  used,  the  formats 
for  displays,  and  the  type  of  symbols  to  be 
used.  Also,  clear  lines  of  authority  and 
responsibility  should  be  established.  The 
remainder  of  this  section  discusses  the  logi¬ 
cal  steps  that  should  be  followed  in  pre¬ 
paring  schedules,  to  include  sources  of 
information,  tools  and  techniques,  and  the 
outputs  of  the  steps.  These  steps  are  based 
on  those  described  in  the  Program  Man¬ 
agement  Institute's  Guide  to  the  Program 
Management  Body  of  Knowledge.*  While  they 
present  a  somewhat  different  approach 
than  the  IMP/IMS  method,  they  have  ge¬ 
neric  applicability  over  the  range  of  plan¬ 
ning  methods. 

3.4.1  Activity  Definition 

This  step  involves  the  identification  and 
definition  of  those  activities  that  must  be 
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accomplished  to  achieve  the  objectives. 
The  WBS  is  a  logical  source  for  such 
descriptions.  If  a  WBS  is  not  available, 
more  planning  must  be  done  in  order  to 
identify  project  activities  clearly.  Other 
inputs  to  the  definition  step  are  the  pro¬ 
gram  scope,  historical  information,  pro¬ 
gram  constraints  and  assumptions,  and 
events  required  by  the  Planning,  Program¬ 
ming,  and  Budgeting  System  (PPBS),  the 
requirements  generation  system,  and  DoD 
acquisition  management  process. 

Decomposition  and  templates  are  tech¬ 
niques  commonly  used  in  activity  defini¬ 
tion.  Decomposition  involves  the  succes¬ 
sive  breakdown  of  program  elements  into 
smaller,  more  manageable  components, 
which  eventually  describe  the  activities  to 
be  scheduled.  This  technique  is  essen¬ 
tially  the  same  used  in  WBS  development. 
A  template  is  an  activity  list  or  WBS  ele¬ 
ment  from  another  similar  program  that 
can  serve  as  a  model  for  the  current  pro¬ 
gram  and  provide  a  starting  point  for  de¬ 
fining  specific  activities. 

The  primary  output  of  this  step  is  the  activ¬ 
ity  list,  which  should  contain  a  complete 
description  of  each  of  the  activities  neces¬ 
sary  to  complete  the  program.  This  list 
should  be  linked  to  the  WBS,  which  should 
be  reviewed  and  revised/clarified  as  nec¬ 
essary  to  incorporate  changes  resulting 
from  the  activity  definition  process.  Sup¬ 
porting  details  for  each  activity,  such  as 
constraints  and  assumptions,  should  also 
be  developed  and  documented. 

3.4.2  Activity  Sequencing 

This  step  involves  the  accurate  identifica¬ 
tion  of  constraints  /  relationships  among  ac¬ 
tivities  and  establishing  the  order  in  which 
the  activities  will  be  accomplished. 


There  are  several  inputs  to  this  step: 

•  The  activity  list  developed  in  the  activ¬ 
ity  definition  step, 

•  The  product  description  and  character¬ 
istics, 

•  Mandatory  constraints/dependencies, 
such  as  the  fact  that  a  prototype  must  be 
fabricated  before  it  can  be  tested, 

•  Discretionary  constraints/depend¬ 
encies  developed  by  the  program  manage¬ 
ment  team  based  on  "best  practices"  or 
specific  sequences  desired  by  management, 

•  External  dependencies,  such  as  avail¬ 
ability  of  test  sites,  and 

•  Other  constraints  and  assumptions. 

A  number  of  tools  and  techniques  are  use¬ 
ful  in  developing  the  logic  diagrams  that 
reflect  the  desired  activity  sequencing. 
They  include  various  network  scheduling 
techniques  that  are  discussed  in  Chapters  4 
and  6.  In  addition,  a  number  of  scheduling 
software  programs  develop  activity  se¬ 
quencing.  Their  selection  and  use  are  dis¬ 
cussed  in  Chapter  9. 

The  output  of  this  step  is  a  network  dia¬ 
gram  that  reflects  the  sequence  of  activities 
based  on  the  inputs  described  above.  This 
diagram  should  be  augmented  with  a 
narrative  description  of  the  sequencing  ap¬ 
proach  and  a  detailed  discussion  of  any 
unusual  or  complex  sequences.  Activity 
lists  should  be  reviewed  and  revised  to 
reflect  any  changes  necessitated  by  activity 
sequencing. 
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3.4.3  Activity  Duration  Estimating 

Activity  duration  estimating  is  the  determi¬ 
nation  of  the  time  required  to  complete  the 
activities  that  make  up  the  program.  This 
is  one  of  the  most  difficult  aspects  of  sched¬ 
ule  development  and  should  be  performed 
by  people  who  are  most  familiar  with  the 
activity.  Two  key  inputs  to  the  estimation 
process  are  the  resources  required  and  as¬ 
signed  for  the  activity  and  the  capabilities 
of  the  resources  assigned.  Historical  infor¬ 
mation  from  other  programs  and  from  com¬ 
mercial  databases  can  also  be  helpful  in 
developing  accurate  estimates. 

The  following  techniques  are  commonly 
used  in  estimating  activity  durations: 

•  Expert  judgment  guided  by  historical 
information, 

•  Analogous  estimating  based  on  expe¬ 
rience  of  similar  programs, 

•  Parametric  estimating  based  on  formu¬ 
las  describing  relationships  among  pro¬ 
gram  parameters  and  time,  and 

•  Use  of  simulation  to  develop  distri¬ 
butions  of  probable  duration  of  each 
activity. 

The  output  of  this  step  is  an  estimate  of  the 
likely  amount  of  time  to  complete  each 
activity.  These  estimates  should  also  in¬ 
clude  a  range  of  possible  values,  e.g.,  3 
weeks  ±  1  week,  and  a  clear  statement  of 
the  assumptions  made  in  the  estimation 
process. 

3.4.4  Schedule  Development 

This  step  involves  the  development  of 
realistic  start  and  finish  dates  for  each 


activity.  An  iterative  process,  schedule 
development  takes  into  account  activity 
sequencing,  duration  estimates,  resource 
requirements  and  availability,  calendars 
that  show  when  work  can  be  performed, 
constraints,  assumptions,  and  risk. 

The  output  of  this  step  is  a  set  of  sched¬ 
ules  for  the  program.  These  include  the 
master  program  schedule  and  the  support¬ 
ing  detailed  schedules,  which  should  re¬ 
flect  the  best  balance  possible  between  com¬ 
peting  demands  of  time  and  resources. 
They  should  also  take  into  account  the  risk 
associated  with  time,  cost,  and  performance 
tradeoffs  and  the  impact  on  the  overall 
program. 

A  number  of  techniques  and  tools  are  useful 
in  developing  schedules,  many  of  which  are 
contained  in  various  scheduling  software 
applications.  Many  of  these  applications 
contain  the  capability  to  perform  various 
types  of  mathematical  analyses  to  calculate 
theoretical  start  and  finish  dates  for  each 
activity  based  on  the  overall  sequencing  of 
the  program  activities.  Two  of  the  more 
commonly  known  analysis  techniques  are 
critical  path  method  (CPM)  and  the  Pro¬ 
gram  Evaluation  and  Review  Technique 
(PERT).  They  are  discussed  in  greater 
detail  in  Chapter  6. 

Other  scheduling  development  techniques 
that  are  commonly  used  focus  on  schedule 
development  in  light  of  resource  (time, 
people,  funds,  material)  constraints.  These 
techniques  provide  the  means  to  manage  the 
affect  of  these  constraints  through  the  com¬ 
pression  of  activity  duration  and  the  leveling 
of  resources  throughout  activities.  Schedule 
compression  and  resource  leveling  are  dis¬ 
cussed  in  more  detail  in  Chapter  6. 
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3.4.5  Schedule  Control 

The  final  step  in  the  schedule  preparation 
process  is  to  identify  schedule  variations  and 
to  manage  actual  changes  to  the  developed 
schedules.  A  schedule  change  control  sys¬ 
tem  that  defines  the  procedures  by  which 
changes  can  be  made  should  be  established 
and  integrated  into  the  program's  overall 
change  control  system.  The  schedule 
change  control  system  should  address  such 
things  as  the  methods  of  schedule  perfor¬ 
mance  tracking  and  the  approval  process 
for  authorizing  changes.  The  need  for  sched¬ 
ule  changes  can  be  caused  by  a  number  of 
factors,  to  include: 

•  Failure  to  achieve  planned  dates  for 
specific  activities  or  events, 

•  Internal  program  management  assess¬ 
ment  and  replanning,  and 

•  External  direction,  such  as  reallocation 
of  funding. 

When  evaluating  these  factors,  it  is  im¬ 
portant  to  determine  what,  if  any,  sched¬ 
ule  change  is  necessary.  For  example,  if 
an  activity  that  is  not  on  the  critical  path  is 
not  completed  as  planned,  it  may  not  have 
any  effect  on  the  overall  program  sched¬ 
ule.  Consequently,  it  may  not  require  any 
significant  schedule  change. 

The  schedule  change  control  system 
should  also  include  procedures  for  imple¬ 
menting  schedule  changes.  Such  proce¬ 
dures  should  address  the  requirement  to 
keep  all  program  stakeholders,  especially 
the  users,  advised  of  any  significant  sched¬ 
ule  changes.  They  should  also  address  the 
process  for  adjusting  the  schedule  baseline 
and  the  overall  program  plan  when  neces¬ 
sary  schedule  changes  are  severe.  The 


change  control  system  can  also  serve  as  a 
good  database  of  lessons  learned.  Conse¬ 
quently,  information  concerning  sched¬ 
ule  variations,  their  evaluation,  and  the 
development  of  corrective  actions  should 
be  documented  and  made  readily  avail¬ 
able  to  members  of  the  program's  man¬ 
agement  team,  and  to  other  programs. 

3.5  SCHEDULE  RISK 

In  Chapter  2,  we  discussed  the  relation¬ 
ship  between  risk  management  and  pro¬ 
gram  scheduling.  In  this  section,  we  dis¬ 
cuss  the  risk  associated  with  the  program 
schedule.  Uncertainty  exists  in  every 
schedule.  It  is  impossible  to  predict,  with 
complete  confidence,  the  length  of  time 
necessary  to  complete  an  activity,  meet  a 
milestone,  or  deliver  a  system.  Little  in¬ 
formation  exists  in  the  early  phases  of  a 
program,  and  planners  must  rely  on  per¬ 
sonal  experience  and  the  estimates  of  ex¬ 
perts.  As  a  program  progresses  through 
the  acquisition  cycle,  more  information 
becomes  available.  Schedules  developed 
in  the  latter  phases  of  a  program  are  based 
on  more  information  and  analyses,  but 
they  still  lack  complete  certainty.  Uncer¬ 
tainty  introduces  the  element  of  risk  in  the 
planning  process.  Schedule  risk  is  the 
likelihood  of  failing  to  meet  schedule  plans 
and  the  effect  of  that  failure. 

When  creating  a  schedule,  or  when  deter¬ 
mining  overall  program  risk,  the  PM  must 
assess  the  risk  associated  with  the  sched¬ 
ule.  One  technique  for  assessing  this  sched¬ 
ule  risk  involves  estimate  contributions 
for  each  activity's  duration  and  aggregat¬ 
ing  these  distributions  using  a  Monte  Carlo 
simulation  or  other  analytical  tools.  The 
resulting  program-level  schedule  is  then 
analyzed  to  determine  the  actual  sched¬ 
ule  risk  and  to  identify  the  schedule  risk 
drivers. 
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This  technique  uses  a  range  of  times  that  it 
will  take  to  complete  each  activity  instead 
of  single-point  estimates.  This  approach 
results  in  a  more  realistic  estimate  of  sched¬ 
ule  risk  because  it  accounts  for  much  of  the 
uncertainty  inherent  in  the  use  of  single¬ 
point  estimates.  Their  use  invariably  leads 
to  underestimating  the  time  required  to 
complete  the  program  and,  therefore, 
schedule  overruns,  primarily  because  the 
point  estimates  do  not  adequately  address 
the  uncertainty  inherent  in  the  individual 
activities. 

This  range  of  values  for  each  activity  de¬ 
fines  a  probability  distribution  for  the  du¬ 
ration  of  the  activity.  These  distributions 
are  then  combined  to  determine  the  pro¬ 
gram-level  schedule  estimate.  This  ap¬ 
proach  enables  PMs  to  estimate  early  in  a 
program  if  there  is  a  significant  likelihood 
of  overrunning  the  program  schedule  and 
by  how  much.  It  also  identifies  program 
activities  that  are  on  the  "highest  risk  path." 

This  technique  can  be  used  in  any  acqui¬ 
sition  phase  beginning  with  the  comple¬ 
tion  of  the  first  statement  of  work.  The 
schedule  probability  distribution  function 
for  each  key  activity  should  be  developed 
as  soon  as  the  activity  is  included  in  the 
master  schedule.  The  distribution  func¬ 
tions  should  be  periodically  reviewed  and 
revised,  if  necessary,  at  least  once  per  phase. 

The  technique  should  be  applied  by  a  small 
government-industry  team  consisting  of 
schedule  analysts  and  technical  experts 
who  understand  the  significance  of  previ¬ 
ous  risk  performance  assessments.  See  the 
DSMC  Risk  Management  Guidebook5  or  the 
Defense  Acquisition  Deskbook ,  Section  2.52  A6 
for  more  details  on  the  application  of  this 
technique. 

3.6  SUMMARY 

Scheduling  is  critical  to  the  successful  exe¬ 
cution  of  the  planning  and  controlling 
functions  of  program  management.  In  the 


planning  phase,  it  contributes  to  the 
development  of  detailed  functional  plans 
and  budgets  and  to  identification  and  allo¬ 
cation  of  required  resources  throughout 
program  activities.  During  this  phase  is 
developed  a  set  of  integrated  multi-lay¬ 
ered  schedules  that  tie  together  all  pro¬ 
gram  activities,  showing  their  logical  rela¬ 
tionships  and  any  constraints.  The  level  of 
detail  developed  for  these  schedules  de¬ 
pends  on  program  scope  and  risk.  This 
process  provides  a  hierarchy  of  functional 
and  layered  schedules  that  can  be  useful  in 
monitoring  and  controlling  program 
progress. 

Effective  program  control  depends  on  some 
form  of  integrated  cost,  schedule,  and  tech¬ 
nical  performance  management,  such  as 
the  earned  value  management  system 
(EVMS).  Effective  scheduling  is  key  to  the 
success  of  this  technique.  EVMS  criteria  do 
not  dictate  the  use  of  specific  scheduling 
techniques.  However,  they  do  seek  for¬ 
mality,  consistency,  and  discipline 
throughout  the  scheduling  process. 

A  five-step  process  for  schedule  prepara¬ 
tion  that  is  commonly  used  in  program/ 
project  management  includes: 

•  Activity  definition, 

•  Activity  sequencing, 

•  Activity  duration  estimation, 

•  Schedule  development,  and 

•  Schedule  control. 

Risk  is  inherent  in  all  programs,  and  sched¬ 
uling  is  one  element  of  risk.  Uncertainty 
introduced  in  estimating  the  duration  of 
each  activity  causes  most  schedule  risk. 
PMs  must  assess  the  likelihood  of  failing 
to  meet  schedule  plans  and  the  impact  of 
that  failure.  Probabilistic  techniques  have 
proven  to  be  very  useful  in  conducting 
these  assessments. 
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Figure  3-3.  Program  Schedule/Structure  (Example) 
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2  Defense  Systems  ManagementCollege,  Earned  Value  Management  Textbook,  Fort  Belvoir,  VA,  April  16, 1998, 

3  Ibid. 

4  Program  Management  Institute,  A  Guide  to  the  Program  Management  Body  of  Knowledge,  Newtown  Square,  PA, 
1996. 

5  Defense  Systems  Management  College,  Risk  Management  Guidebook,  Fort  Belvoir,  VA,  May  1999. 

6  Information  on  schedule  risk  techniques  is  in  the  Risk  Assessment  Techniques  of  the  Front  Line  Wisdom 
&  Advice  portion  of  Section  2.5.2  A,  Defense  Acquisition  Deskbook. 
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4 

SCHEDULE  TYPES  AND  THEIR  EVOLUTION 


4.1  INTRODUCTION 

Previous  chapters  of  this  guide  stress  the 
point  that  scheduling  is  an  intrinsic,  indis¬ 
pensable  part  of  program  management  and 
a  key  output  of  the  planning  function  of 
that  process.  They  also  describe  the  rela¬ 
tionship  between  the  program  Work  Break¬ 
down  Structure  and  scheduling,  and  intro¬ 
duce  the  concepts  of  the  Integrated  Master 
Plan  and  the  Integrated  Master  Schedule. 
Properly  prepared  and  accurate  schedules 
are  invaluable  tools  in  the  overall  manage¬ 
ment  of  programs.  They  provide  a  road 
map  of  where  the  project  is  going,  the 
resources  required  to  accomplish  the  vari¬ 
ous  project  tasks,  a  means  to  determine 
progress,  and  an  effective  way  to  present 
status  information.  This  chapter  contains 
information  on  the  various  types  of  sched¬ 
ules  generally  in  use  today,  their  character¬ 
istics,  advantages  and  disadvantages,  and 
how  they  have  evolved.  Subsequent  chap¬ 
ters  provide  more  detailed  information  on 
each  of  the  schedule  types,  along  with  in¬ 
formation  on  the  selection  and  use  of 
scheduling  software. 

4.2  SCHEDULE  TYPES 

Schedules  can  be  presented  in  a  variety  of 
ways.  Regardless  of  how  they  are  dis¬ 
played,  schedules  essentially  convey  in¬ 
formation  concerning  one  (or  a  combina¬ 
tion)  of  the  following  categories: 

•  Activities  or  tasks  to  be  accomplished 
over  a  period  of  time,  and 


•  Events  or  milestones,  that  take  place  at 
a  point  in  time,  such  as  a  Defense  Acquisi¬ 
tion  Board  (DAB)  milestone  review. 

Dependencies  or  constraints  among  activi¬ 
ties  or  events.1 

Currently,  four  types  of  schedules  are  in 
common  use  and  depict  the  categories  of 
information  described  above.  They  are  the 
Gantt  or  bar  chart,  the  milestone  schedule  / 
chart,  the  network  schedule,  and  the  pro- 
ductionschedule.  The  evolution,  character¬ 
istics,  and  uses  of  each  of  these  schedules 
are  described  in  the  following  paragraphs, 
and  a  more  detailed  treatment  of  each  of 
them  is  contained  in  subsequent  chapters. 

4.2.1  Gantt  and  Milestone  Charts 

Gantt  charts  and  milestone  charts  are  nor¬ 
mally  combined  to  show  a  program's  sched¬ 
ule;  therefore,  they  are  discussed  in  this 
context.  The  Gantt  chart  is  used  to  provide 
information  concerning  activities.  It  is  com¬ 
monly  referred  to  as  a  bar  chart,  since  it 
depicts  an  activity  as  a  horizontal  bar  im¬ 
posed  over  a  time-line,  or  calendar.  It 
shows  the  planned  start  and  finish  dates 
for  the  activity  and  may  provide  informa¬ 
tion  about  task  progress,  including  sched¬ 
ule  slips  or  gains.  Figure  4-1  is  an  example 
of  a  simple  Gantt  chart  that  shows  the 
planned  schedule  for  four  activities. 
Progress  in  accomplishing  each  activity 
can  be  shown  on  each  of  the  bars,  as  shown 
by  the  shaded  portions  of  activities  1  and  2. 
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The  Gantt  chart  was  the  first  formal  sched¬ 
uling  technique  developed.  It  dates  back 
to  the  early  20th  century  when  Henry  L. 
Gantt  first  introduced  it  while  working  at 
the  Frankford  Arsenal  during  World  War 
I.  It  was  developed  to  provide  a  more 
formal  and  systematic  way  to  schedule 
tasks  when  time  was  an  imprtant  factor. 

The  Gantt  chart  has  survived  in  its  basic 
form  to  this  day  and  continues  to  be 
widely  used  as  a  scheduling  tool  at  all 
levels  within  organizations.  Its  value 
lies  in  its  simplicity  and  its  ability  to 
convey  considerable  information  in  a 
clear  and  concise  manner.  In  the  past,  the 
principal  shortcoming  of  the  traditional 
Gantt  chart  was  its  inability  to  clearly 
depict  dependencies  or  constraints 
among  activities,  making  it  difficult  to 
analyze  schedules  and  optimize  the  allo¬ 
cation  of  resources  to  the  activities.  Some 
scheduling  software  programs  now  make 
it  possible  to  show  relationships,  thereby 


improving  its  utility.  The  Gantt  chart  is 
very  useful  in  reporting  project  status  and 
in  managing  individual  activities  or  simple 
projects  with  few  tasks. 

Subsequent  to  the  development  of  the  Gantt 
chart,  planners  and  managers  used  a  simi¬ 
lar  approach  to  depict  information  about 
significant  project  events,  focusing  on  spe¬ 
cific  points  in  time.  These  events  repre¬ 
sented  project  milestones — hence  the  in¬ 
troduction  of  the  milestone  chart.  The  mile¬ 
stone  chart  shows  when  an  event  is  sched¬ 
uled  and  when  it  is  actually  accomplished. 
Figure  4-2  is  an  example  of  a  milestone 
chart  showing  the  status  of  four  events; 
each  of  these  events  represents  the  comple¬ 
tion  of  the  four  activities  shown  in  the 
example  Gantt  chart  in  Figure  4-1. 

Like  the  Gantt  chart,  the  strength  of  this 
milestone  chart  as  a  scheduling  technique 
lies  in  its  relative  simplicity  and  its  ability 
to  concisely  display  project  information. 
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Figure  4-1.  Gantt  Chart  Example 
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especially  at  the  "big  picture"  level.  How¬ 
ever,  it  does  have  shortcomings  that  limit 
its  effectiveness  in  day-to-day  project  man¬ 
agement.  As  shown  in  Figure  4-2,  the  mile¬ 
stone  chart  can  depict  the  events  corre¬ 
sponding  to  the  completion  of  an  activity. 

However,  it  does  not  reflect  the  progress  in 
accomplishing  the  activity.  In  this  case,  a 
manager  relying  on  this  milestone  chart 
information  could  be  surprised  if  the 
planned  completion  date  is  not  achieved. 
With  no  warning  or  indicators  of  schedule 
slippage,  the  manager  loses  any  flexibility 
in  attacking  the  underlying  problems  caus¬ 
ing  the  slippage.  This  shortcoming  can  be 
compensated  for  by  the  addition  of  interme¬ 
diate  events  or  through  the  use  of  combined 
Gantt  and  milestone  charts.  This  is  discussed 
in  more  detail  in  the  next  chapter. 

Another  weakness  of  the  milestone  chart  is 
the  difficulty  to  clearly  visualize  the 
relationships,  dependencies,  and  con¬ 
straints  among  the  various  project/pro- 
gram  activities  and  events.  In  spite  of  these 
shortcomings,  the  milestone  chart  can  be 
an  effective  way  of  presenting  the  project 
or  program  status  at  higher  levels  of  man¬ 
agement  review. 


Perhaps  the  biggest  shortfall  of  the  Gantt 
and  milestone  charts  is  that  neither  of 
them,  nor  the  combination  of  both,  allow 
detailed  schedule  analysis.  However, 
every  PM  must  know  and  understand 
Gantt  and  milestone  charts  for  two  simple 
reasons:  everybody  uses  them,  and  nor¬ 
mally,  one  of  the  first  steps  in  the  planning 
process  is  to  construct  a  schedule  using  a 
Gantt  chart. 

4.2.2  Network  Schedules 

Network  scheduling  was  developed  to 
overcome  the  primary  shortcoming  of  the 
Gantt  and  milestone  charts — the  inability 
to  clearly  portray  the  relationships,  depen¬ 
dencies,  and  constraints  among  the  project 
activities  and  events.  A  network  schedule 
is  a  graphical  display  of  a  project,  includ¬ 
ing  a  representation  of  these  relationships. 
Figure  4-3  shows  an  example  of  a  network 
schedule  for  a  simple  project. 

In  this  example,  the  lines  represent  project 
activities  A  through  H;  the  nodes  repre¬ 
sent  the  events  associated  with  the  begin¬ 
ning  and  end  of  the  activities.  The  net¬ 
work  shows  the  following  constraints 
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among  the  activities:  activity  A  must  be 
completed  before  activities  B,  C,  or  D  can 
begin;  B  must  be  completed  before  E  can 
begin;  F  cannot  begin  until  D  is  completed; 
G  cannot  begin  until  C  and  E  are  done,  and 
H  cannot  begin  until  F  and  G  are  com¬ 
pleted.  In  addition  to  showing  this  type  of 
sequencing  constraints,  network  schedules 
can  also  show  the  time  and  resources 
planned  for  each  activity  and  thus  provide 
managers  with  a  mechanism  to  monitor 
and  control  the  project.  A  later  chapter 
covers  network  schedules  in  detail. 

The  advent  of  network  schedules  can  be 
traced  back  to  the  1920s  and  the  evolu¬ 
tion  of  operations  research.  Analysts  re¬ 
alized  the  inability  to  depict  dependen¬ 
cies  and  constraints  was  a  major  short¬ 
coming  of  existing  scheduling  techniques, 
and  attempted  to  solve  the  problem 
through  the  application  of  network  theory. 
The  translation  of  this  theory  into  a  usable 
scheduling  tool  was  hindered  by  the  in¬ 
ability  to  process  network-related  data 
in  a  timely  fashion.  The  development  of 
the  computer  provided  the  means  to  au¬ 
tomate  this  data  processing  and,  by  the 
1950s,  the  concept  of  network  scheduling 


was  being  applied  to  large,  complex  pro¬ 
grams.  The  first  major  network  schedul¬ 
ing  technique  developed  was  the  Pro¬ 
gram  Evaluation  and  Review  Technique, 
or  PERT,  which  was  used  as  a  manage¬ 
ment  tool  for  scheduling  and  controlling 
the  Navy's  Polaris  missile  program.  PERT 
enables  managers  to  visualize  the  entire 
program,  see  interrelationships  and  de¬ 
pendencies,  and  recognize  when  and 
where  delays  are  acceptable.  One  of  the 
key  features  of  PERT  is  the  use  of  prob¬ 
ability  techniques  to  develop  a  set  of  time 
estimates  for  each  program  activity,  mak¬ 
ing  it  particularly  well-suited  for  pro¬ 
grams  where  it  is  difficult  to  make  accu¬ 
rate  estimates  with  high  confidence.  Con¬ 
current  with  the  development  of  PERT, 
the  construction  industry  developed  a 
network  scheduling  system  based  on  the 
concept  of  critical  path.  A  project's  criti¬ 
cal  path  is  the  most  time-consuming  route 
through  the  network  activities  that  must 
be  completed  in  order  to  finish  the  project. 
This  approach,  named  Critical  PathMethod 
(CPM),  was  designed  to  focus  on  perfor¬ 
mance  time  and  total  program  cost.  Some 
publications  refer  to  CPM  as  the  Arrow 
Diagram  Method  (ADM). 
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PERT  and  CPM  scheduling  techniques  have 
many  similarities.  For  example,  each  shows 
the  relationships  among  activities  and 
events,  both  include  the  project's  critical 
path,  and  the  structure  of  each  allows  analy¬ 
sis  of  the  tasks  to  be  done,  resources  as¬ 
signed  to  do  them,  and  the  time  associated 
with  each  task.  Both  techniques  use  nodes  to 
represent  events  (beginning  and  end  of  ac¬ 
tivities)  and  lines  to  represent  the  activities. 

A  third  network  scheduling  technique  is  the 
Precedence  Diagram  Method  (PDM),  which 
was  developed  subsequent  to  the  PERT/ 
CPM  techniques.  Its  function  is  to  permit  a 
more  accurate  depiction  of  relationships 
among  various  activities  than  is  possible 
using  the  other  two  techniques.  PERT/ 
CPM  techniques  are  essentially  limited  to 
"finish-start"  relationships  (i.e.,  activity  B 
cannot  start  until  activity  A  is  completed). 
The  PDM  technique  can  depict  other  rela¬ 
tionships  that  permit  a  more  accurate  and 
realistic  portrayal  of  the  program's  activi¬ 
ties,  such  as  "start-start"  (i.e.,  activity  B 
cannot  start  until  activity  A  starts).  The 
technique  accomplishes  this  through  the 
use  of  nodes  to  depict  activities  and  lines  to 
depict  relationships.  These  three  techniques 
are  discussed  in  greater  detail  in  Chapter  6. 
Network  scheduling  techniques  provide 
managers  with  a  powerful  tool  for  schedul¬ 
ing  and  controlling  their  programs/ projects. 
In  general,  they  permit  the  graphic  por¬ 
trayal  of  project  activities  and  relationships 
among  the  activities.  This  provides  the 
basis  for  determining  the  project's  critical 
path,  predicting  shortages,  and  identifying 
possible  reallocation  of  resources  to  solve 
problems.  Through  the  use  of  readily  avail¬ 
able  software,  network  schedules  are  fairly 
easy  to  update  and  rework,  thus  providing 
managers  with  current  program/project 
status  information  and  control  over  activi¬ 
ties  and  schedules. 


In  spite  of  the  strengths  of  network  schedul¬ 
ing  techniques,  there  are  some  limitations. 
The  value  of  network  schedules  is  directly 
dependent  on  the  validity  of  the  time  esti¬ 
mates  for  each  activity.  In  addition,  it  is 
sometimes  difficult  to  accurately  portray 
all  activities  and  relationships,  especially 
for  very  large,  complex  programs.  Thus, 
considerable  "up  front"  work  is  required 
to  develop  an  effective  network  schedule. 
Detailed  networks,  once  developed,  tend 
to  be  the  focus  of  management  attention 
when,  in  fact,  there  will  undoubtedly  be 
other  factors  not  on  the  display  that  will 
require  management  attention. 

4.2.3  Production  Schedules 

Production  scheduling  involves  the  plan¬ 
ning,  execution,  and  control  of  repetitive 
activities,  such  as  the  manufacture  of  a 
large  number  of  identical  items.  Efficient 
production  requires  the  proper  balance  of 
materials,  facilities,  and  personnel  skills.  It 
also  requires  a  means  to  monitor  the 
production  process. 

The  Line  of  Balance  (LOB)  technique,  while 
not  truly  a  scheduling  tool,  is  such  a  moni¬ 
toring  technique  that  can  provide  early 
warning  of  potential  problems  that  can 
affect  program  schedule.  It  is  especially 
useful  for  monitoring  repetitive  processes 
where  it  is  essential  to  balance  inventory 
acquisition  with  the  production  process 
and  delivery  requirements.  The  LOB  tech¬ 
nique  consists  of  four  elements:  (1)  objec¬ 
tives  of  the  program,  i.e.,  contract  sched¬ 
ule  and  actual  deliveries;  (2)  production 
plan;  (3)  current  program  status  or  inven¬ 
tory;  and  (4)  a  comparison  between  where 
the  program  is  and  where  it's  supposed  to 
be,  (that  is,  program  inventories  versus 
the  LOB).  These  elements  are  discussed  in 
more  detail  in  Chapter  7. 
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The  origin  of  LOB  is  not  clear,  but  it  is 
believed  it  was  developed  to  help  manage 
defense-related  contracts  in  the  1940s  and 
50s.  It  is  still  used  today  in  both  defense  and 
commercial  industry.  While  government 
PMs  or  their  staffs  will  probably  not  need  to 
directly  develop  or  apply  the  LOB  tech¬ 
nique,  they  should  understand  it  and  real¬ 
ize  that  it  can  be  a  valuable  tool  for  contrac¬ 
tors  to  monitor  the  status  of  production 
contracts  and  to  present  status  information. 

This  technique  can  point  out  problems  be¬ 
fore  their  impact  on  finished  product  deliv¬ 
eries  shows  up,  thereby  allowing  managers 
to  make  corrections.  It  also  allows  manag¬ 
ers  to  see,  in  the  middle  of  a  contract,  whether 
they  can  meet  the  contract  schedule  if  they 
continue  working  as  they  have  been.  An¬ 
other  advantage  of  LOB  is  that  it  focuses 
attention  on  the  production  activities  where 
there  are  problems,  thereby  facilitating  ini¬ 
tiation  of  corrective  action. 

There  are  some  limitations  with  the  LOB 
technique.  First,  it  is  best  suited  for  produc¬ 
tion  and/or  assembly-type  processes  that 
are  stable.  The  activities  that  make  up  the 
production  plan  must  be  definable  and  well 
understood.  Second,  while  this  technique 
pinpoints  where  a  problem  exists,  it  cannot 
identify  the  specific  problem. 

4.3  SUMMARY 

Each  scheduling  method  has  strengths  and 
limitations.  Program  Mangers  must  be  fa¬ 
miliar  with  all  of  the  techniques  and  choose 


the  method  that  allows  them  to  meet  their 
goals.  The  choice  of  schedule  type  depends 
on  a  number  of  factors,  such  as,  the  purpose 
of  the  schedule,  its  intended  use,  and  the 
decisions  to  be  made  from  the  information 
presented.  For  example,  day-to-day  man¬ 
agement  of  a  project  consisting  of  a  number 
of  related  and  complex  activities  may  re¬ 
quire  a  schedule  that  depicts  the  tasks,  their 
planned  duration,  dependencies,  progress, 
and  resources  allocated  to  each  of  them.  If 
a  PM  must  do  detailed  schedule  analysis  of 
this  type  of  project,  then  the  PM  will  most 
likely  use  a  network  schedule.  This  method 
is  the  only  way  to  use  probability  distribu¬ 
tions  for  time  estimates  rather  than  complet¬ 
ing  an  activity  and  project  in  a  certain  time. 

On  the  other  hand,  the  management  of  a 
single  activity  may  require  a  schedule  that 
reflects  only  the  time  planned  for  accom¬ 
plishing  the  task  and  the  current  status. 
Schedules  showing  only  events,  such  as  the 
completion  dates  of  planned  activities,  or 
bar  charts  may  be  sufficient  in  those  cases 
when  the  audience  may  not  be  concerned 
with  the  details  of  the  activities. 

As  a  rule  of  thumb,  Gantt  and  milestone 
charts  are  useful  to  present  information  and 
summarize  program  activities.  They  are 
also  usually  the  starting  points  for  detailed 
planning  and  creating  a  network  schedule. 
Network  schedules  are  usually  created  for 
detailed  planning  and  analyses.  They  are 
necessary  to  determine  the  feasibility  of 
meeting  program  goals,  assessing  risk,  and 
conducting  sensitivity  analyses. 
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5 

GANTT  AND  MILESTONE  CHARTS 


5.1  DESCRIPTION 

As  discussed  in  Chapter  4,  the  Gantt  chart 
is  one  of  the  oldest  planning  tools  in 
existence  and  is  still  used  today  at  all 
levels  of  project  management.  For  ex¬ 
ample,  PMs  use  Gantt  charts  to  report 
information  concerning  program  activi¬ 
ties  at  milestone  decision  briefs,  while 
engineers  may  use  them  to  manage  the 
tasks  associated  with  design  activities. 
Because  PMs  often  use  Gantt  and  mile¬ 
stone  charts  to  report  information  to  re¬ 
view  groups,  they  are  treated  jointly  in 
this  chapter. 

In  its  simplest  form,  a  Gantt  chart  is  a 
schedule  that  shows  the  start/ stop  dates 
of  a  program's  individual  activities.  It 
uses  symbols  superimposed  on  a  calen¬ 
dar  to  provide  information  about  the 
original  plan,  the  status  of  the  activity, 
and  any  forecasted  changes  to  the  plan. 


There  is  no  standard  set  of  Gantt  chart  sym¬ 
bols.  Planners  should  define  them  and  con¬ 
sistently  use  them  throughout  the  chart.  Fig¬ 
ure  5-1  shows  an  example  of  the  symbols  that 
could  be  used  in  Gantt  charts. 

The  schedule  is  displayed  as  a  series  of  hori¬ 
zontal  bars  representing  the  duration  of  ac¬ 
tivities.  A  manager  may  show  actual  progress 
against  the  schedule  by  shading  in  each  bar 
as  activity  progresses  or  may  use  a  colored 
bar  that  is  parallel  to  the  schedule  bar.  Figure 
5-2  shows  a  simple  Gantt  chart  that  illustrates 
activities  involved  indeveloping  components 
of  a  weapons  system.  This  type  of  display 
ca  nbe  useful  for  conveying  information  about 
the  program  to  those  involved  in  its  review 
or  those  charged  with  its  day-to-day  man¬ 
agement. 

From  this  example,  we  can  see  that  as  of  late 
March,  the  design,  fabrication,  and  assembly 
of  the  payload  are  ahead  of  schedule,  [A]. 


Symbol 

Meaning 

AZ 

_ V 

Planned  activity  schedule 

■ 

m — 

Status  of  activity 

zz: 

v~x 

Forecasted  completion  behind  schedule 

zz: 

— 

Forecasted  completion  ahead  of  schedule 

Figure  5-1.  Example  Gantt  Chart  Symbols 
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Figure  5-2.  Example  Gantt  Chart 


Based  on  this  information,  and  an  analysis  of  the  guidance  and  control  subsystem  is 

of  the  activities,  the  PM  has  revised  the  not  going  as  well  as  planned.  As  of  late- 

planned  completion  date  for  the  payload  March,  the  fabrication  is  well  behind  sched- 

fabrication,  [B].  In  analyzing  the  current  ule,  [D].  After  reviewing  the  progress  and 

status,  the  PM  has  determined  that  much  of  remaining  work,  the  PM  has  slipped  the 

the  work  in  payload  assembly  will  have  to  planned  completion  dates  for  the  fabrica- 

be  done  toward  the  end  of  the  planned  tion  and  assembly  activities,  [E],  They  be- 

activity  period.  (In  other  words,  the  work  lieve  that  it  is  too  early  to  revise  the  planned 

is  not  uniformly  distributed  throughout  completion  dates  for  test  and  rework,  and 

the  period.)  Thus,  even  though  this  activity  the  system  integration  and  test  activities, 

is  ahead  of  schedule  now,  the  PM  has  However,  the  slippage  already  experienced 

decided  not  to  revise  the  planned  comple-  should  serve  as  a  warning  that  this  entire 

tion  date  for  assembly  and  test,  [C].  This  development  effort  may  be  in  trouble  and 

Gantt  chart  also  shows  that  development  will  require  dose  monitoring. 
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While  the  Gantt  chart  focuses  on  activities 
and  their  duration,  the  milestone  chart  fo¬ 
cuses  on  planned  significant  events  sched¬ 
uled  to  occur  at  specific  times  in  the  pro¬ 
gram.  Such  events  could  be  the  initiation 
or  completion  of  a  particularly  important 
or  critical  activity,  equipment  deliveries, 
reviews,  or  approval  dates.  Like  the  Gantt 
chart,  the  milestone  chart  uses  symbols 
imposed  on  a  calendar  to  provide  informa¬ 
tion  about  planned  and  actual  completion 
dates  and  any  revisions  to  the  milestone 
schedule.  There  is  no  standard  set  of  sym¬ 
bols  for  milestone  charts.  Figure  5-3  shows 
the  symbols  prescribed  for  reporting  mile¬ 
stone  information  within  the  Air  Force 
Material  Command.  Different  scheduling 
software  will  often  use  unique  symbols. 


The  important  thing  is  that  the  symbols  be 
clearly  defined  and  consistently  applied. 

Figure  5-4  shows  an  example  milestone 
chart  for  the  program  described  in  the 
Gantt  chart  in  Figure  5-2.  Note  that  events 
displayed  correspond  to  the  beginning  of 
some  activities  and  the  completion  of  all  of 
them.  Other  events  displayed  represent 
important  occurrences  and  key  decision 
points  within  each  of  the  activities,  e.g., 
preliminary  and  critical  design  reviews, 
"make  or  buy"  decision,  etc.  In  this  ex¬ 
ample,  we  see  that  as  of  late-March  pay- 
load  design  has  progressed  on  schedule, 
[A],  and  that  planned  completion  date  for 
fabrication  has  been  revised  ahead  of  the 
original  schedule,  [B],  As  discussed  in  the 


Standard  symbols  have  been  adapted  for  Air  Force  milestone 
schedules.  The  most  common  symbols  used  and  their  meanings  are 
shown  below. 

Basic  Symbol 

Meaning 

0 

Schedule  Completion 

* 

Actual  Completion 

£ 

Previous  Scheduled  Completion — Still  in  Future 

Previous  Scheduled  Completion — Date  Passed 

Representative  Uses 

Meaning 

£  0 

Anticipated  Slip — Rescheduled  Completion 

Actual  Slip— Rescheduled  Completion 

1  i 

Actual  Slip— Actual  Completion 

1 

Actual  Completion  Ahead  of  Schedule 

Time  Span  Action 

0  o 

Continuous  Action 

Figure  5-3.  Example  Milestone  Chart  Symbols 
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J 

F 

D 

M 

D 

D 

D 

0 

N 

D 

Payload  Design 

Begin  Payload  Design 

Payload  Preliminary  Design  Review  (PDR) 
Payload  Critical  Design  Review  (CDR) 
Complete  Payload  Design 

Payload  Fabrication 

Make  or  Buy  Decision 

Tooling  Complete 

Fabrication  Complete 

Assemble  Payload 

Begin  Assembly 

Delivery  of  Parts  Complete 

Assembly  Complete 

Payload  Test  &  Rework 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

Guidance  &  Control  Design 

Begin  G&C  Design  \ 

G&C  PDR 

G&C  CDR 

Complete  G&C  Design 

Fabricate  G&C 

Make  or  Buy  Decision 

Tooling  Complete 

Fabrication  Complete 

Assemble  G&C 

Begin  Assembly 

Delivery  of  Parts  Complete 

Assembly  Complete 

Test  and  Rework 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

Integrate  Payload  and  G&C 

Begin  Integration 

Complete  Integration 

Test  &  Rework 

Test  Plan  Complete 

Test  Readiness  Review 

Test  &  Rework  Complete 

t 

k 

t 

i 

_£ _ * _ St _ 

i 

k 

t 

\ 

t 

t 

\) 

i 

0 

{ 

a<=>  „  <P  o  ^ 

0 

ft 

[D] 

ft 

! 

0 

k 

ft 

[D] 

ft 

[D] 

ft 

ft 

ft 

*1 

ft 

r 

ft 

ft 

Now 


Figure  5-4.  Example  Milestone  Chart 
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Payload  Design 


Payload  Preliminary  Design  Review  (PDR) 
Payload  Critical  Design  Review  (CDR) 
Complete  Payload  Design 

Payload  Fabrication 

Make  or  Buy  Decision 
Tooling  Complete 
Fabrication  Complete 

Assemble  Payload 

Delivery  of  Parts  Complete 
Assembly  Complete 

Payload  Test  &  Rework 

Test  Plan  Complete 
Test  Readiness  Review 
Test  &  Rework  Complete 

Guidance  &  Control  Design 

G&C  PDR 
G&C  CDR 

Complete  G&C  Design 

Fabricate  G&C 

Make  or  Buy  Decision 
Tooling  Complete 
Fabrication  Complete 

Assemble  G&C 

Delivery  of  Parts  Complete 
Assembly  Complete 

Test  and  Rework 

Test  Plan  Complete 
Test  Readiness  Review 
Test  &  Rework  Complete 

System  Integration  Payload  and  G&C 

Complete  Integration 

System  Test  &  Rework 

Test  Plan  Complete 
Test  Readiness  Review 
Test  &  Rework  Complete 


a  o 


♦  t 


o  u 


°0% 


Figure  5-5.  Example  Combination  Chart 
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As  discussed  in  the  Gantt  chart  example, 
there  are  problems  in  the  fabrication  of  the 
guidance  and  control  subsystem.  One  of 
the  events  selected  as  a  milestone  was  the 
completion  of  the  tooling  necessary  for 
fabrication.  From  the  example,  we  see  that 
this  event  experienced  an  actual  slip  of 
approximately  one  month,  [C];  this,  in  turn, 
has  caused  the  Program  Manager  to  revise 
the  scheduled  completion  dates  for  fabri¬ 
cation,  parts  delivery,  and  assembly,  [D]. 

Managers  rarely  use  pure  Gantt  or  mile¬ 
stone  charts.  Normally  they  integrate  the 
information  from  these  charts  and  display 
it  in  a  combination  chart.  Such  a  chart  can 
be  useful  in  displaying  the  planned  and 
actual  duration  of  activities  using  the  Gantt 
chart  symbols  and  in  monitoring  the 
progress  for  completing  key  events  in  these 
activities  using  the  milestone  symbols.  Fig¬ 
ure  5-5  is  a  combination  chart  showing  the 
activities  and  events  described  in  Figures 
5-2  and  5-4. 

Whereas  the  simple  Gantt,  milestone,  or 
combination  charts  may  be  suitable  for 
reporting  program  status,  most  managers 
need  additional  information  to  plan,  moni¬ 
tor,  and  control  activities.  New  software 
applications  increase  the  utility  of  these 
charts  by  making  it  easy  to  add  informa¬ 
tion,  such  as  budget,  cost,  resources,  etc. 

Today's  programs  use  databases  to  store 
related  schedule  information  and  then  al¬ 
low  users  to  filter,  sort,  and  display  infor¬ 
mation  in  a  variety  of  ways.  They  also 
allow  users  to  tailor  the  software  to  their 
needs  by  adding  customized  information 
to  the  database.  Figure  5-6  shows  how  to 
display  the  relationship  of  one  activity  with 
another  by  drawing  lines  between  related 
activities.  The  Budget  column,  in  which  the 
manager  enters  the  budgeted  cost  for  the 


activity,  is  a  standard  feature  of  the  par¬ 
ticular  program  used  to  create  this  Gantt 
chart.1  The  Assignment,  Cost,  and  Cost/Bud¬ 
get  ratio  columns  are  not  standard  features 
but  were  added  to  the  database  to  demon¬ 
strate  how  the  charts  may  be  customized  to 
meet  individual  needs.  Note  that  the  user 
may  create  computation  fields,  such  as  the 
percentage  and  totals  fields  shown  in  the 
figure. 

5.2  CONSTRUCTING  GANTT  AND 
MILESTONE  CHARTS 

Gantt  and  milestone  charts  are  relatively 
easy  to  construct  when  compared  to  the 
complexity  of  network  charts.  The  first 
step  is  to  decide  the  level  at  which  the 
project  is  to  be  planned,  tracked,  and  re¬ 
ported.  This  decision  should  consider  such 
things  as  the  needs  of  the  entire  project 
team,  and  the  degree  of  risk  associated 
with  the  various  program  activities.  Most 
likely  there  will  be  a  need  to  manage  and 
track  at  a  low  level  and  report  at  a  higher 
level.  Current  scheduling  software  has  the 
capability  to  handle  activities  at  various 
program  levels  allowing  insight  and  man¬ 
agement  at  the  lower  levels  and  permitting 
roll  up  of  information  at  higher  levels  for 
reporting  purposes.  To  accomplish  this, 
charts  must  be  developed  in  a  logical  and 
consistent  manner. 

The  next  step  in  constructing  the  charts  is 
the  identification  of  activities  and  mile¬ 
stones  to  be  displayed,  tracked,  and  moni¬ 
tored.  The  WBS  should  be  used  as  the 
primary  source  for  this  identification.  If  a 
WBS  is  not  available,  or  if  it  does  not  go 
down  to  the  necessary  level,  additional 
planning  must  be  done  to  clearly  define 
and  identify  activities  to  be  managed, 
tracked,  and  reported.  Other  sources  for 
identifying  activities  and  events  include 
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the  Acquisition  Strategy,  the  Acquisition 
Program  Baseline,  the  Risk  Management 
Plan,  and  the  Integrated  Management  Plan, 
and  the  Integrated  Management  Plan. 

5.3  GANTT  AND  MILESTONE 
CHART  ADVANTAGES  AND 
DISADVANTAGES 

Gantt  and  milestone  (or  combination)  charts 
provide  a  simple,  effective  means  to  present 
project  information,  and  a  way  to  monitor 
and  control  smaller  projects.  Using  these 
charts  as  scheduling  tools  has  many  advan¬ 
tages,  but  also  limitations  that  should  be 
understood.  These  pros  and  cons  are  pre¬ 
sented  below.  Evolving  scheduling  soft¬ 
ware  includes  features  that  overcome  some 
of  the  shortcomings  to  varying  degrees. 

5.3.1  Advantages 

(1)  Simple  to  prepare  and  update, 

(2)  Information  portrayed  in  easily  un¬ 
derstood  format, 

(3)  Relatively  inexpensive  to  prepare 
using  software  tools, 

(4)  Relate  activities  and  calendar  dates, 

(5)  Easy  to  roll  up  information  into  sum¬ 
mary  form, 

(6)  Useful  first  step  for  preparation  of 
more  complex  type  schedules 

(7)  Reliable  estimates  can  be  developed 
when  the  work  is  repetitive  and  when  the 
product  is  easy  to  measure  quantitatively. 


5.3.2  Disadvantages 

(1)  Difficult  to  use  for  detailed  sched¬ 
ule  analysis 

(2)  Do  not  show  the  effects  of  late  or 
early  activity  starts 

(3)  Do  not  represent  dependencies 
among  activities  as  well  as  other  schedul¬ 
ing  methods 

(4)  Do  not  reflect  the  uncertainty  in  the 
planned  activity  duration  or  event  date 

(5)  Only  as  reliable  as  the  estimates  on 
which  they  are  based;  looking  at  the  chart 
doesn't  indicate  which  estimates  are  the 
most  reliable 

(6)  Do  not  allow  quick  or  easy  explora¬ 
tion  of  the  consequences  of  alternative  ac¬ 
tions. 

5.4  HOW  AND  WHEN  GANTT  AND 
MILESTONE  CHARTS  ARE 
EMPLOYED 

Gantt  and  milestone  charts  are  best  used 
for  displaying  the  planned  activities  and 
events  of  a  project  and  the  progress  in 
meeting  them.  This  makes  them  very  use¬ 
ful  for  presenting  schedule  and  program 
status  information  in  a  concise  simple  for¬ 
mat  at  such  things  as  programor  activity 
reviews. 

Because  of  its  simplicity  and  ease  of  inter¬ 
pretation,  it  is  a  particularly  good  tool  for 
communicating  to  higher  management 
when  information  must  be  presented 
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quickly  and  efficiently.  These  charts  may 
also  be  sufficient  for  management  and  con¬ 
trol  of  simple  projects.  However,  they 
have  limited  utility  for  managing  more 
complex  projects,  since  they  do  not  easily 
capture  interrelationships  among  activi¬ 
ties  and  events  or  reflect  the  uncertainty 
associated  with  time  and  resource  esti¬ 
mates.  Generally,  they  do  not  provide  the 
level  of  information  necessary  for  the  effec¬ 
tive  monitoring  and  control  of  such  projects. 


5.5  SUMMARY 

As  scheduling  tools,  Gantt  and  milestone 
charts  provide  a  simple  and  effective  means 
for  displaying  actual  versus  planned 
progress  of  a  program  and  for  showing 
schedule  changes  that  have  occurred.  The 
major  drawback  of  Gannt  and  milestone 
charts  is  the  limited  degree  fo  detail  and 
dependency  information  they  can  portray. 
However,  recently  developed  software 
scheduling  applications  now  make  it  pos¬ 
sible  to  show  more  of  the  relationships 
among  project  activities  and  events. 


_ ENDNOTES _ 

1  This  figure  is  an  adaptation  of  sample  charts  from  Fast  Track  Schedule  sample  charts. 
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6 


NETWORK  SCHEDULING 


6.1  DESCRIPTION 

Driven  by  the  increase  in  project  complex¬ 
ity,  managers  developed  the  need  for  bet¬ 
ter  schedule  and  control  methods  than  those 
provided  by  Gantt  and  milestone  charts. 
The  shortcomings  of  these  charts  gave  rise 
to  network  scheduling.  Over  time,  differ¬ 
ent  applications  of  network  theory  were 
developed  to  address  the  needs  of  manag¬ 
ers.  Today,  essentially  three  networking 
techniques  are  in  use:  the  Program  Evalu¬ 
ation  and  Review  Technique  (PERT);  the 
Critical  Path  Method  (CPM)  [these  two 
techniques  are  also  known  as  Arrow  Dia¬ 
gram  Methods  (ADM)]  and  the  Precedence 
Diagram  Method  (PDM).  Each  is  discussed 
later  in  this  chapter. 

All  of  these  techniques  provide  the  man¬ 
ager  with  powerful  tools  to  plan,  analyze, 
monitor,  and  control  the  project  and  to 
manage  the  resources  necessary  to  accom¬ 
plish  project  tasks.  They  can  help  the  man¬ 
ager  answer  the  following  questions: 

•  When  is  each  activity  or  task  of  the 
program  scheduled  to  begin  and  end? 

•  Which  activities  must  be  finished  on 
time  to  avoid  missing  the  scheduled  pro¬ 
gram  completion  date? 

•  Can  resources  be  shifted  to  critical  parts 
of  the  program  (those  that  must  be  com¬ 
pleted  on  time)  from  noncritical  parts  (those 
considerable  effort  and  the  involvement  of 


Accomplishing  these  things  may  requirethat 
can  be  delayed)  without  affecting  the  over¬ 
all  scheduled  completion  date  for  the  pro¬ 
gram? 

•  Among  program  tasks,  where  should 
management  efforts  be  concentrated  at  any 
particular  time? 

Networks  are  a  graphical  portrayal  of  the 
activities  and  events  of  a  project.  They  show 
how  each  activity  relates  to  others  in  the 
project,  the  sequence  of  activities,  and  the 
need  to  perform  some  tasks  before  others. 
Figure  4-3  is  an  example  of  an  ADM  net¬ 
work  schedule.  Networks  also  facilitate  the 
determination  of  the  impact  of  early  or  late 
starts  or  finishes,  provide  information  about 
the  allocation  of  resources,  and  allow  man¬ 
agers  to  do  "what  if"  analyses.  With  this 
information,  managers  may  view  the  status 
of  the  plan,  analyze  progress,  and  evaluate 
alternatives. 

To  apply  these  networking  techniques,  the 
following  conditions  must  exist: 

•  All  program  activities  must  be  clearly 
defined,  including  identifiable  start  and 
completion  points. 

•  A  logic  diagram  showing  the  sequence 
and  interrelationships  of  activities  must  be 
developed. 

•  The  time  to  complete  each  activity  must 
be  estimated  as  accurately  as  possible. 
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people  familiar  with  the  overall  project  and 
those  responsible  for  executing  various 
groups  of  activities.  This  up-front  effort 
provides  an  understanding  of  project  re¬ 
quirements  and  early  identification  of 
potential  problem  areas. 

6.1.1  PERT 

In  1958,  the  U.S.  Navy  introduced  the  con¬ 
cept  of  network  scheduling  techniques  by 
developing  PERT  as  a  management  con¬ 
trol  system  for  the  development  of  the 
Polaris  missile  program.  The  focus  of  PERT 
was  to  give  managers  the  means  to  plan 
and  control  processes  and  activities  so  the 
project  could  be  completed  within  the  speci¬ 
fied  time  period.  The  Polaris  program  in¬ 
volved  250  prime  contractors,  more  than 
9,000  subcontractors,  and  hundreds  of 
thousands  of  tasks. 

PERT  was  introduced  as  an  event-oriented, 
probabilistic  technique  to  increase  a  PM's 
control  in  projects  where  time  was  the  criti¬ 
cal  factor  and  time  estimates  were  difficult 
to  make  with  confidence.  The  events  used 
in  this  technique  represent  the  start  and 
finish  of  the  activities.  PERT  uses  three 
time  estimates  for  each  activity:  optimistic, 
pessimistic,  and  most  likely.  From  these 
estimates,  an  expected  time  is  calculated 
based  on  a  beta  probability  distribution  for 
each  activity.  The  developers  of  PERT  chose 
the  beta  probability  distribution  because  it 
could  accommodate  nonsymmetrical  situ¬ 
ations.  They  assumed  that  the  probability 
of  an  estimate  being  too  optimistic  would 
not  be  equal  to  the  probability  that  the 
same  estimate  would  be  too  pessimistic. 
That  is,  if  estimated  times  could  be  com¬ 
pared  against  actual  completion  times  in  a 
number  of  cases,  the  variation  would  look 
like  the  curve  in  Figure  6-1. 


The  expected  time,  t  is  the  weighted  aver¬ 
age,  or  mean  time,  for  an  activity  based  on 
the  beta  distribution  and  is  determined 
from  the  following  formula: 

a  +  Am  +  b 

t= - 

6 

Using  the  expected  times  and  other  statis¬ 
tical  properties  of  the  beta  distribution  for 
each  activity,  determine  an  expected  time 
for  completion  of  the  project  and  the  likeli¬ 
hood  (probability)  that  it  will  be  met.  It  is 
also  possible  to  determine  the  critical  path 
for  the  project — the  most  time-consuming 
path  through  the  network  activities  and 
events  to  project  completion.  Any  delay 
will  delay  the  completion  of  the  project. 

PERT  is  most  useful  when  it  is  difficult  to 
either  accurately  estimate  the  time  required 
for  project  activities  or  to  determine  the 
percentage  of  work  accomplished  within 
an  activity.  The  percentage  of  work  accom¬ 
plished  can  be  especially  important  when 
analyzing  the  adequacy  of  resources  ap¬ 
plied  to  an  activity.  Projects  best  suited  for 
PERT  are  one-of-a-kind  complex  programs 
that  involve  new  technology  or  processes 
and  research  and  development. 

Following  the  success  of  the  Polaris  pro¬ 
gram,  PERT  became  widely  used  through¬ 
out  the  systems  acquisition  community,  to 
include  attempts  to  combine  it  with  cost 
data  or  other  nonscheduling  aspects  of  pro¬ 
gram  management.  As  a  result,  PERT  be¬ 
came  so  cumbersome  that  the  cost  of  main¬ 
taining  it  far  outweighed  the  benefit.  Con¬ 
sequently,  the  use  of  PERT  declined  and, 
by  the  1970s,  it  was  only  occasionally  em¬ 
ployed  in  defense  system  programs.  Over 
the  last  few  years,  it  has  again  become 
relatively  popular,  particularly  in  the  pri¬ 
vate  sector.  This  resurgence  is  due,  in  part, 
to  the  development  of  PERT  software  or 
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Figure  6-1.  Beta  Distribution  with  PERT  Time  Estimates 


other  networking  software  programs  that 
can  be  run  on  microcomputers. 

In  spite  of  misuses  that  have  occurred  in 
PERT  applications,  the  technique  can  be  a 
very  useful  tool  because  it  enables  the  man¬ 
ager  to  visualize  the  entire  program,  see 
interrelationships  and  dependencies,  and 
recognize  when  delays  are  acceptable. 
Thus,  the  manager  is  better  able  to  assess 
problems  as  the  program  evolves. 

6.1.2  CPM  or  PERT 

The  CPM  scheduling  technique  was  intro¬ 
duced  at  approximately  the  same  time  as 
PERT.  '  It  was  developed  by  J.  E.  Kelly  of 
Remington-Rand  and  M.  R.  Walker  of 
DuPont  to  aid  in  scheduling  maintenance 
shutdowns  in  chemical  processing  plants. 
Over  the  years,  CPM  has  enjoyed  more  use 
than  any  other  network  scheduling  tech¬ 
nique.  It  is  based  on  the  concept  of  critical 
path  and  was  designed  to  focus  on  the  time 
and  resources,  particularly  cost,  necessary 
to  complete  the  activities  of  a  project. 


Although  CPM  and  PERT  are  conceptu¬ 
ally  similar,  some  significant  differences 
exist,  most  as  a  result  of  the  type  of  projects 
best  suited  for  each  technique.  As  discussed 
earlier,  PERT  is  better  to  use  when  there  is 
much  uncertainty  and  when  control  over 
time  outweighs  control  over  costs.  PERT 
handles  uncertainty  of  the  time  required  to 
complete  an  activity  by  developing  three 
estimates  and  then  computing  an  expected 
time  using  the  beta  distribution.  CPM  is 
better  suited  for  well-defined  projects  and 
activities  with  little  uncertainty,  where  ac¬ 
curate  time  and  resource  estimates  can  be 
made,  and  the  percentage  of  completion  of 
an  activity  can  be  determined.  In  CPM, 
because  of  the  greater  certainty,  a  single 
time  estimate  is  used.  This  estimate  is  the 
time  planned  for  the  activity  under  normal 
conditions;  it  approximates  the  most  likely 
time  estimate  in  PERT.  The  normal  cost 
estimate  is  the  cost  associated  with  finish¬ 
ing  the  program  in  the  normal  time.  A 
second  time  and  cost  estimate,  the  crash 
estimate,  is  also  used  in  the  CPM  tech¬ 
nique.  The  crash  time  estimate  is  the  time 
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that  will  be  required  to  finish  an  activity  if 
a  special  effort  is  made  to  reduce  program 
time;  crash  cost  is  the  cost  associated  with 
performing  the  effort  on  a  crash  basis  so  as 
to  reduce  the  time  to  completion.  This  is 
discussed  in  more  detail  with  a  later  ex¬ 
ample. 

CPM  is  activity-oriented,  concentrating  on 
activity  start  (early  start,  late  start)  and 
finish  times  (early  finish,  late  finish); 
whereas  PERT  is  event-oriented,  concen¬ 
trating  on  early  event  time  and  late  event 
time.  The  network  diagrams  used  for  CPM 
and  PERT  are  essentially  the  same  (see 
Figure  4-3),  as  are  the  procedures  for  using 
them.  As  discussed  earlier,  certain  actions 
are  essential  to  applying  network  schedul¬ 
ing  techniques.  The  activities / events  com¬ 
posing  the  project,  the  relationships  among 
them,  and  their  time  estimates  must  be 
identified,  and  a  network  diagram  devel¬ 
oped.  Once  the  diagram  is  completed,  the 
following  procedures  are  applied: 

•  Complete  and  annotate  the  cumulative 
time  required  to  reach  each  node  along  the 
paths — this  will  indicate  the  earliest  time 
work  can  start  on  the  next  activity.  The  final 
number  will  indicate  total  time  required  to 
complete  a  particular  path. 

•  Identify  the  critical  path — this  is  the 
sequence  of  events,  or  route,  taking  the 
longest  time  to  complete. 

•  Starting  at  the  program  completion  node 
on  the  right  side  of  the  diagram,  begin 
working  backward  and  compute  the  latest 
time  an  activity  can  start  without  delaying 
the  overall  program — for  example,  if  the 
total  program  takes  40  weeks  and  the  final 
activity  requires  5  weeks,  this  activity  can¬ 
not  begin  later  than  week  35.  For  CPM,  the 
difference  between  the  latest  and  earliest 


start  of  an  activity  is  the  slack  or  float.  The 
critical  path  contains  no  slack  or  float  time. 
For  PERT,  the  difference  between  the  earli¬ 
est  event  time  and  the  latest  event  is  the 
slack/ float  time. 

The  use  of  these  procedures  is  illustrated 
in  a  later  example. 

6.1.3  PDM 

PDM  is  an  activity-oriented  technique  that 
was  developed  subsequent  to  PERT  and 
CPM.  The  impetus  behind  this  develop¬ 
ment  was  the  need  for  greater  flexibility  in 
dealing  with  relationships  and  constraints 
between  project  activities.  PERT/CPM,  or 
the  arrow  diagram  method  (ADM),  essen¬ 
tially  treats  all  relationships  as  "finish-to- 
start"  constraints;  that  is.  Activity  A  must  be 
completed  before  Activity  B  begins.  There 
are  ways  within  PERT  /  CPM  to  circumvent 
this  limitation,  but  they  are  cumbersome 
and  add  more  complexity  to  the  technique. 

The  PDM  technique  provides  the  capability 
to  treat  other  types  of  relationships  that 
occur  in  complex  projects.  Figure  6-2  shows 
examples  of  these  types  of  relationships  or 
constraints. 

In  addition  to  depicting  different  rela¬ 
tionship  between  activities,  PDM  also 
handles  time  lags  that  would  normally  oc¬ 
cur  as  the  project  progresses.  Examples  of 
such  lags  are  the  time  required  for  the  move¬ 
ment  of  parts  or  components  from  one  activ¬ 
ity  site  to  another,  or  the  timeinvolved  in  the 
reallocation  of  resources — people,  equip¬ 
ment,  and  facilities.  Figure  6-3  shows  ex¬ 
amples  of  constraint  lags  and  how  they  can 
be  depicted.  These  lags  could  be  repre¬ 
sented  as  activities  in  either  ADM  or  PDM 
techniques,  but  this  could  add  needless 
complexity  to  the  schedule. 


38 


Figure  6-2.  Example  PDM  Relationships/Constraints 


PDM  uses  the  same  underlying  principles  lines  represent  the  activities  and  the  rela- 
as  the  other  networking  techniques:  clearly  tionship /constraints.  Activity  time  and 

defined  activities,  accurate  time  estimates,  resource  estimates  are  normally  shown  on 

critical  path,  etc.  The  difference  between  the  lines.  In  PDM,  the  nodes  represent  the 

PERT/CPM/ADM  and  PDM  is  in  the  way  activities  and  are  normally  shown  as  rect- 

the  network  is  portrayed.  In  PERT/CPM,  angles.  Activity  identifiers,  time  and  re- 

the  network  nodes  represent  the  events  as-  source  estimates,  early  and  late  start  and 

sociated  with  activities  (i.e.,  the  beginning  finish  dates,  and  other  appropriate  infor- 

and  end  of  activities),  and  the  connecting  mation  are  normally  shown  in  the  boxes. 
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Figure  6-4  is  an  example  of  an  activity 
node.  The  lines  connecting  the  nodes  rep¬ 
resent  the  relationships  between  the  activi¬ 
ties,  e.g.,  finish-to-start,  start-to-start,  etc. 
The  use  of  PDM  is  demonstrated  later. 


6.2  NETWORK  SCHEDULING 
ADVANTAGES  AND 
DISADVATAGES 

Network  scheduling  techniques  provide 
the  mechanisms  necessary  to  conduct  a 


Symbols 


Lag  +  5  days 


Lag  +  7  days 


Lag  -  5  day 


Constraint 


Finish-to-Start  with  Lag 
B  cannot  start  until  5  days  after  A 
is  completed 


Start-to-Start  with  Lag 
B  cannot  start  until  7 
days  after  A  has  started 


Finish-to-Start  with  Negative  Lag 
B  cannot  start  until  5  days  before  A 
is  completed 


Figure  6-3.  Example  PDM  Constraints  with  Lag  Time 


Early  Start  Time 

Early  Finish  Time 

7/12/99 

7/14/99 

Duration 
3  Days 


Activity  Identification 
Information 


Resource 

Requirements 


Late  Start  Time 

Late  Finish  Time 

7/14/99 

7/16/99 

Figure  6-4.  Example  PDM  Activity  Node 
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systematic,  disciplined,  and  thorough  re¬ 
view  of  what  will  be  required  to  conduct 
and  complete  a  project.  Such  an  approach 
is  essential  for  large,  complex  projects  and 
is  also  useful  in  managing  smaller,  less 
complicated  projects.  The  advantages  and 
disadvantages  of  these  techniques  are  iden¬ 
tified  below. 

6.2.1  Advantages 

•  Provide  graphical  portrayal  of  project 
activities  and  relationsnips/ constraints, 

•  Force  communications  among  team 
members  in  identifying  activities, 

•  Organize  what  would  otherwise  be  con¬ 
fusing  material,  making  it  easier  for  man¬ 
agers  to  make  tradeoffs  and  develop  alter¬ 
native  plans, 

•  Provide  capabilities  to  evaluate  progress 
and  control  project, 

•  Allow  managers  to  predict  shortages 
and  act  on  them  early, 

•  Once  prepared,  permit  easy  update  and 
rework, 

•  Give  managers  more  control  over  ac¬ 
tivities/events  and  schedules, 

•  Facilitate  "what  if"  exercises, 

•  Provide  the  basis  for  Gantt  and  mile¬ 
stone  chart  information,  and 

•  Show  resources  associated  with 
activities  and  time. 

6.2.2  Disadvantages 

•  Network  construction  can  be  difficult 
and  time  consuming. 

•  Only  as  sound  as  the  activity  time  and 
resource  estimates. 


•  Sometimes  difficult  to  portray  graphi¬ 
cally — too  many  lines,  nodes  and  intersec¬ 
tions. 

•  Not  particularly  good  for  conveying 
information  in  briefings/ reviews. 

•  Complex  networks,  once  sketched  out 
on  a  large  wall  chart,  tend  to  become  the 
focus  of  management  attention  when,  in 
fact,  a  manager  should  be  paying  attention 
to  factors  not  on  the  chart,  such  as  manage¬ 
ment/labor  relations. 

6.3  HOW  AND  WHEN  NETWORK 
SCHEDULES  ARE  EMPLOYED 

Network  scheduling  techniques  canbe  very 
useful  in  complex  projects  that  involve 
new  technologies  or  processes  and  that  are 
not  repetitive,  such  as  production.  They 
are  not  particularly  easy  to  use  for  presen¬ 
tations  because  of  their  complexity;  how¬ 
ever,  they  canbe  used  as  the  basis  for  other 
scheduling  techniques  that  are  more  suit¬ 
able  for  presentation  of  information,  i.e., 
Gantt  or  milestone  charts. 

Government  managers  may  not  use  net¬ 
work  techniques  in  the  day-to-day  man¬ 
agement  of  their  programs.  However,  they 
should  have  an  understanding  of  the  tech¬ 
niques  to  ensure  that  contractors  are  using 
them  when  appropriate. 

The  different  types  of  network  scheduling 
techniques  have  many  similarities.  How¬ 
ever,  each  of  them  provides  different  types 
of  information  that  can  be  useful  to  manag¬ 
ers  in  evaluating  progress,  developing 
alternatives,  and  managing  the  allocation 
of  resources  within  their  projects.  The  fol¬ 
lowing  examples  show  the  types  of  infor¬ 
mation  resulting  from  each  technique  and 
how  managers  may  use  them. 
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6.3.1  PERT  Example 

Figure  6-5  shows  a  PERT  network  for  a 
project  containing  8  activities  (A-H),  with 
the  nodes  1-7  representing  the  beginning 
and  end  of  the  activities.  The  three  time 
estimates  discussed  earlier  in  this  chapter 
are  shown  for  each  activity.  For  example, 
for  Activity  A,  the  time  estimates  are  opti¬ 
mistic  time=l  week,  most  likely  time=2 
weeks,  and  pessimistic  time=3  weeks.  The 
expected  time  estimate  for  each  activity,  f, 
as  derived  from  the  formula  associated 
with  Figure  6-1,  is  also  shown.  From  this 
information,  the  project  critical  path  can  be 
computed  by  adding  the  time  estimates 
along  all  paths  leading  to  project  comple¬ 
tion.  In  this  example,  the  critical  path  is 
determined  as  follows: 

Path  A-B-E-H=2 +3+2+4=11  weeks 
Path  A-C-F-H=2+4+3+4=13  weeks 
Path  A-D-G-H=2+8+9+4=23  weeks 

Thus,  path  A-D-G-H  is  the  critical  path 
since  it  requires  the  greatest  time.  Any 
delay  along  this  path  will  cause  a  delay  in 
project  completion.  The  other  paths  are 
shorter  than  the  critical  path  and,  there¬ 


fore,  contain  activities  that  can  be  com¬ 
pleted  before  they  are  required.  Therefore, 
delays  along  these  paths  may  not  result  in 
delays  in  project  completion.  In  the  above 
example,  critical  path  activities,  D  and  G, 
will  require  17  weeks  to  complete.  On  path 
A-B-E-H,  activities  B  and  E  will  require  5 
weeks  to  complete.  Thus,  there  will  be  12 
weeks  of  slack  along  that  path.  Actually, 
this  slack  is  only  along  path  B,  E  since  A 
and  H  are  on  the  critical  path.  Likewise 
path  C-F  has  10  weeks  of  slack  time.  This 
concept  of  slack  time,  sometimes  called 
float  time  or  path  slack/ float,  is  important 
because  it  allows  managers  to  reschedule 
activities  not  on  the  critical  path  to  use 
resources  efficiently. 

The  following  description  of  how  slack 
time  is  computed  is  intended  to  illustrate 
the  concept  that  managers  can  use  it  to  their 
advantage.  Fortunately,  software  programs 
compute  slack  time  and  managers  do  not 
have  to  make  these  calculations. 

Slack  time  should  be  computed  for  each 
activity  in  the  network.  One  way  of  doing 
this  is  by  comparing  the  earliest  time  an 
activity  can  begin,  TE,  to  the  latest  time  the 


Figure  6-5.  PERT  Example 
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activity  can  begin,  TL.  The  difference  is  the 
activity  slack  time.  For  all  activities  on  the 
critical  path,  TEand  TL  have  the  same  value. 
To  determine  the  values  of  TE  and  TL  for 
each  activity,  start  with  the  node  represent¬ 
ing  the  beginning  of  the  first  activity  and 
assign  it  a  value  of  TE=TL=0.  Follow  the 
critical  path  and  add  the  activity  time  esti¬ 
mate  to  the  value  of  TE  of  the  preceding 
node  to  get  the  value  of  TE  for  the  next 
node.  For  example,  the  node  at  the  comple¬ 
tion  of  Activity  A  and  the  beginning  of 
Activity  D  has  a  value  of  TE=TL=2.  Figure 
6-6  shows  how  TE  and  TL  can  be  depicted 
on  a  network  chart.  Continue  along  the 
critical  path  to  node  7,  which  has  a  value  of 
Te=Tl=23,  the  time  required  to  complete 
the  project.  Next,  compute  the  values  for 
Te  for  the  remaining  activities  and  nodes 
not  on  the  critical  path.  The  value  of  TE  for 
node  3  is  the  value  of  TE  from  node  2  (TE=2) 
plus  the  duration  of  Activity  B;  for  node  3, 
Te=5. 

To  determine  the  latest  starting  times  for 
each  activity,  begin  at  the  completion  of  the 
project  and  work  backward  through  the 
activities.  Since  Activity  H  is  on  the  critical 
path,  its  value  of  TL=19.  Activity  E  is  not  on 


the  critical  path  so  its  value  of  TL  (shown  on 
node  3)  is  the  difference  between  TL  at  node 
6  and  the  time  estimate  for  Activity  E, 
Tl=19-2=17.  The  activity  slack  is  the  differ¬ 
ence  between  TE  and  TL  at  each  node.  For 
Activity  E,  the  slack  is  TL-TE=17-5=12  weeks. 
This  activity  could  start  anytime  between 
weeks  5  and  17  without  any  adverse 
impact  on  the  critical  path.  Activity  B  is  not 
on  the  critical  path  so  its  value  of  TL  is  the 
difference  between  TL  at  node  3  and  the 
time  estimate  for  Activity  B  (17-3=14).  This 
is  not  shown  at  node  2,  since  that  node  also 
represents  the  start  of  Activity  D,  which  is 
on  the  critical  path.  The  slack  for  Activity 
B  is  Tl-Te=14-2=12.  (The  same  approach  is 
used  to  determine  the  slack  for  Activity  C.) 
Slack  is  not  additive  along  a  path;  it  must 
be  shared  by  all  activities  on  the  path. 
Thus,  if  Activity  B  starts  at  week  5  instead 
of  week  2,  Activity  E  would  have  only  9 
weeks  of  slack  available.  Similarly,  Activi¬ 
ties  C  and  F  have  a  slack  of  10  weeks. 

The  concept  of  slack  and  TE  and  TL  can  be 
very  useful  to  managers,  providing  the 
basis  for  resource  allocation  and  also  pro¬ 
viding  the  means  to  determine  the  prob¬ 
ability  of  meeting  the  project  schedule. 


Te=5 

Tl=17 


Figure  6-6.  PERT  Example  with  Slack  Time 
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This  latter  topic  is  beyond  the  intended 
scope  of  this  guidebook;  however,  a  num¬ 
ber  of  available  books  provide  detailed 
discussion  of  the  application  of  PERT 
techniques.  (See  the  bibliography  in  Ap¬ 
pendix  D.) 

6.3.2  CPM  or  ADM  Example 

As  discussed  earlier,  PERT  and  CPM/ 
ADM  are  conceptually  similar,  in  that  both 
techniques  use  the  same  type  of  network 
structure,  and  are  the  concepts  of  critical 
path  and  slack  time.  The  following  ex¬ 
ample  will  be  used  to  illustrate  basic  ap¬ 
plication  of  the  CPM/ADM  technique. 

Figure  6-7  shows  the  same  project  as  used 
in  the  PERT  example,  with  the  single  time 
estimates  for  each  activity.  Table  6-1  shows 
the  time  and  crash  estimates  for  each  of  the 
activities. 

The  critical  path  for  the  CPM  approach  is 
determined  in  the  same  way  as  in  the  PERT 
example.  While  the  concept  of  slack  time 
is  essentially  the  same  as  in  PERT,  it  is 
normally  calculated  in  a  different  manner 
using  four  different  values  for  each  activity: 


•  Earliest  time  the  activity  can  start,  ES 

•  Earliest  time  the  activity  can  finish,  EF 

•  Latest  time  an  activity  can  start,  LS 

•  Latest  time  an  activity  can  finish,  LF. 

To  compute  ES,  start  at  the  first  activity  and 
move  forward  through  the  network  paths. 
The  earliest  Activity  A  can  start  is  at  t=0. 
The  earliest  that  it  can  finish  is  ES  plus  the 
activity  duration;  thus  for  A,  ES=0  and 
EF=2.  The  earliest  start  for  subsequent  ac¬ 
tivities  is  the  EF  of  the  preceding  activity. 
For  Activity  B,  ES=2.  The  earliest  finish 
time  for  each  activity  is  the  earliest  start 
time  plus  the  activity  duration.  For  Activ¬ 
ity  B  this  is  EF=2+3=5.  When  activities 
converge,  such  as  E,  F,  and  G  at  node  6,  the 
earliest  starting  time  for  the  next  activity  is 
the  latest  value  of  EF  of  the  preceding 
converging  activities. 

To  compute  the  latest  times,  make  a  back¬ 
ward  pass  through  the  network,  beginning 
with  the  last  activity.  The  date  to  begin  the 
pass  can  be  either  an  established  required 
date  or  the  early  finish  date  for  the  project 


completion.  The  latest  starting  date  for  the 
final  activity  is  determined  by  subtracting 
the  activity  duration  from  the  date  used  to 
begin  the  pass.  For  subsequent  activities, 
the  latest  finish  date  is  the  same  as  the  latest 
starting  date  for  the  preceding  activity.  In 
the  backward  pass,  the  value  of  LF  for  an 
activity  that  precedes  a  set  of  diverging 
activities  in  the  network  (activity  A  in  the 
example)  is  the  earliest  of  the  values  of  LS 
of  the  diverging  activities  (B,  C,  D). 

The  values  of  ES,  EF,  LS,  and  LF  for  all 
activities  are  shown  in  Figure  6-7.  With  this 
information,  one  can  determine  the  slack 
for  each  activity.  Slack  is  determined  using 
the  following  formula: 

Slack=LF-EF=LS-ES. 

The  relative  certainty  of  time  and  resource 
estimates  enables  managers  to  determine 
the  percent  of  work  completed  in  each 
activity  as  the  project  progresses.  Being 
able  to  estimate  the  percent  of  completion 
provides  managers  with  the  means  to  re¬ 
distribute  resources  if  an  activity  is  falling 
behind  schedule.  For  example,  if  an  activ¬ 
ity  has  fallen  behind  schedule,  it  is  possible 
to  estimate  the  work  remaining  and  the 
cost  of  applying  additional  resources  to 
complete  the  activity  on  schedule. 

Network  scheduling  techniques,  particu¬ 
larly  CPM,  used  on  projects  with  relatively 
certain  time  and  cost  estimates  can  provide 
managers  with  information  to  effectively 
manage  their  projects.  Using  percent  of 
work  completed  or  that  remaining  on  on¬ 
going  activities,  they  can  compare  the 
progress  at  a  certain  time  with  the  original 
plan.  Based  on  this  information,  they  can 
develop  revised  time  and  cost  estimates  for 
these  activities  and  forecast  new  start  and 
completion  dates  for  remaining  activities 


and  a  new  project  completion  date.  They 
can  then  use  the  new  forecast  dates  to 
determine  action  that  can  be  taken  and  the 
appropriate  resource  planning  and  reallo¬ 
cation,  if  necessary. 

The  CPM  technique  provides  managers 
with  the  means  to  investigate  ways  and 
impacts  of  speeding  up,  or  crashing,  the 
schedule.  As  part  of  the  planning  process, 
a  set  of  crash  estimates  should  be  devel¬ 
oped  if  possible.  The  estimates  for  this 
example  are  shown  in  Table  6-1. 

This  table  shows  the  time  and  cost  esti¬ 
mates  and  the  crash  cost  per  week.  To  crash 
a  schedule,  some  key  points  must  be 
considered: 

•  Crash  only  along  the  critical  path. 

•  When  an  activity  is  shortened,  one  or 
more  new  critical  paths  may  emerge.  Paral¬ 
lel  critical  paths  increase  risk  dramatically. 

•  Generally,  least  additional  cost  is  the 
criterion  used  to  select  which  activity  to 
crash,  but  other  considerations  (e.g.,  per¬ 
sonnel  hours)  could  be  used. 

In  this  example,  assume  that  the  project 
must  be  crashed  by  4  weeks  at  the  least 
additional  cost.  Looking  at  the  activities  on 
the  critical  path,  select  the  one  with  the 
lowest  weekly  crash  cost;  in  this  case  it  is 
Activity  D,  which  can  be  crashed  from  8  to 
6  weeks  for  an  additional  $6,000.  Next, 
crash  Activity  G  by  2  weeks  at  a  cost  of 
$10,000.  Reducing  both  of  these  activities 
does  not  change  the  critical  path. 

6.3.3  PDM  Example 

The  PDM  technique  focuses  on  program 
activities  and  the  meaning  of  the  constraints 
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Time  Required 

Cost 

Crash 
Cost  Per 
Week 

Activity 

Normal 

Crash 

Normal 

Crash 

A 

2 

1 

10,000 

16,000 

B 

3 

2 

12,000 

17,000 

5,000 

c 

4 

3 

12,000 

18,000 

D 

8 

6 

20,000 

26,000 

3,000 

E 

2 

- 

11,000 

- 

- 

F 

3 

2 

14,000 

19,000 

5,000 

G 

9 

7 

25,000 

35,000 

5,000 

H 

4 

3 

16,000 

23,000 

7,000 

Table  6-1.  CPM  Example  Time  Estimates 


among  activities.  This  technique  is  used  in 
many  scheduling  software  applications, 
and  it  relies  on  the  same  concepts — critical 
path,  slack  time,  etc.,  as  the  other  network 
scheduling  techniques. 

Figure  6-8  shows  a  PDM  network  for  a 
project  with  Activities  A-I.  Note  that  Activ¬ 
ity  B  cannot  start  until  Activity  A  starts,  and 
Activity  D  cannot  end  until  Activity  C  ends. 
The  critical  path  is  determined  in  essen¬ 
tially  the  same  way.  In  PDM,  however,  one 
must  account  for  the  different  types  of  con¬ 
straints;  e.g..  Activity  D  cannot  be  com¬ 
pleted  until  Activity  C  is  finished — in  this 
case,  9  weeks.  The  critical  path  for  this 
example  is  determined  as  follows: 

Path  A-C-F-I=5+4+5+3+17  weeks 
Path  B-D-G-I=4+(2+3)+2+3=14  weeks 
Path  B-E-H-I=4+5+2+3=14  weeks 

Thus,  Path  A-C-F-I  is  the  critical  path. 

The  slack  times  for  the  activities  are  deter¬ 
mined  in  the  same  way  as  in  the  CPM 
technique,  using  earliest  and  latest  start 
and  finish  times,  ES,  EF,  LS,  LF.  Earliest 
times  are  computed  by  making  a  forward 
pass  through  the  networks  paths,  and  lat¬ 
est  times  are  determined  making  a  back¬ 
ward  pass.  Figure  6-9  shows  the  PDM  net¬ 


work  with  these  values,  using  the  activity 
format  shown  in  Figure  6-4.  Using  the 
formula  for  slack, 

Slack=LS-ES=LF-EF, 

we  see  that  on  path  B-D-G-I,  activities  B,  D, 
and  G  each  have  a  slack  of  3  weeks.  This 
slack  is  not  additive;  if  Activity  D  starts  at 
week  8  vice  week  7,  then  Activity  G  has  only 
2  weeks  of  slack  remaining.  We  also  see  that 
Activities  B,  E,  and  H  have  3  weeks  of  slack 
on  their  path.  If  Activity  B  uses  3  weeks  of 
slack,  none  will  be  left  for  either  path. 

Another  concept  that  can  be  useful  is  that  of 
lag  time.  Lag  time  reflects  the  time  required 
to  transition  from  one  activity  to  another, 
such  as  machine  set-up  time  or  movement 
of  material,  parts,  or  components  from  one 
site  to  another.  It  can  be  shown  on  the  net¬ 
work  and  must  be  accounted  for  in  deter¬ 
mining  critical  path  and  values  of  ES,  EF,  LS 
and  LF.  Figure  6-10  shows  that  in  moving 
from  Activity  D  to  Activity  G,  there  will  be 
a  lag  of  1  week.  The  figure  also  shows  the 
effect  of  this  lag  time  on  the  earliest  and 
latest  start  and  finish  times.  The  resulting 
slack  for  Activities  D  and  G  is  now  2  weeks. 
This  example  shows  that  the  PDM  tech¬ 
nique  provides  considerably  greater  flex¬ 
ibility  in  handling  different  types  of 
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Figure  6-9.  PDM  Example — Early  and  Late  Start  and  Finish  Times 
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8  12  13  14 


Figure  6-10.  PDM  Example  with  Lag  Time 


constraints  than  does  ADM .  Consequently, 
it  is  better  suited  for  in  complex  projects, 
particularly  those  with  a  lot  of  parallel 
activities  and  constraints  other  than  finish- 
to-start. 

6.4  NETWORK  SCHEDULING  WHEN 
RESOURCES  ARE  LIMITED 

In  the  previous  discussion,  the  assump¬ 
tion  was  that  a  new  activity  could  start  as 
soon  as  any  constraints  were  satisfied  be¬ 
cause  sufficient  resources  were  available 
to  perform  the  work.  In  practice,  however, 
resources  to  proceed  are  not  always  avail¬ 
able. 

In  those  situations,  PMs  can  take  one  or 
more  different  actions  to  reduce  the  ad¬ 
verse  impact  on  the  program. 

Those  actions  include: 

•  Adding  additional  resources 


•  Reducing  the  scope  of  the  program 

Adjusting  the  schedule  to  accommodate 
the  resource  shortfall.  In  this  section,  we 
show  how  network  schedules  and  the  con¬ 
cepts  of  critical  path  and  slack  (float)  can  be 
applied  to  make  better  use  of  limited  re¬ 
sources.  Figure  6-11  shows  a  PDM  net¬ 
work  with  activities  A  through  J.  Each 
node  of  the  network  shows  the  number  of 
people  required  to  complete  the  activity 
along  with  the  activity  duration  and 
earliest  and  latest  start  and  finish  times. 

To  determine  adequacy  of  resources 
(people  in  this  example),  assume  each  ac¬ 
tivity  will  start  as  early  as  possible  and 
determine  the  resource  requirements  over 
time.  Figure  6-12  shows  personnel  load¬ 
ing  requirements  by  time  for  the  duration 
of  the  program.  During  week  one,  1 1  people 
are  required  to  work  on  activities  A,  B,  and 
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Figure  6-1 1 .  Network  Schedule  with  Constrained  Resources 

C.  Now,  let's  suppose  only  nine  people  are  are  evened  out  without  scheduling  more 

available  to  work  during  this  11  week  pe-  work  than  nine  people  can  do.  In  this  ex- 

riod.  The  chart  shows  there  will  not  be  ample,  this  rearrangement  can  be  accom- 

sufficient  workers  during  the  first,  fourth,  plished  quickly  by  hand.  However,  with 

and  fifth  weeks.  There  will  be  sufficient  many  activities,  it  becomes  very  difficult  to 

workers  to  perform  the  work  scheduled  find  the  optimum  answer.  Fortunately, 

during  the  second  and  sixth  week.  During  scheduling  software  applications  are  a  vail- 

the  third  and  seventh  throughout  eleventh  able  to  assist  in  solving  the  problem.  Re¬ 
weeks,  there  will  be  a  surplus  of  workers  gardless  of  the  approach  used  (manual  or 

for  the  work  scheduled.  The  task  becomes  automated),  the  resource-leveling  process 

one  of  rearranging  the  schedule  so  that,  is  an  iterative  step-by-step  process  using  a 

insofar  as  possible,  the  peaks  and  valleys  set  of  rules  to  establish  the  priority  of  the 
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Figure  6-12.  Personnel  Loading  Chart 


activities  requiring  the  constrained  resource, 
and  the  actions  to  be  taken. 

As  discussed  earlier,  the  concept  of  float  (or 
slack)  can  be  useful  in  the  efficient  allocation 
of  resources,  and  it  should  be  considered  in 
establishing  the  rules  to  be  followed.  The 
float  demonstrated  in  earlier  examples  is 
commonly  called  path  float.  Another  type  of 
float  that  is  particularly  useful  in  resource 
allocation  is  free  float.  Free  float  is  the  slack 
that  a  single  activity  can  experience  without 
affecting  any  other  activity.1  The  free  float  of 
a  given  activity  is  defined  as  the  difference 
between  earliest  start  of  the  succeeding  activ¬ 
ity  and  earliest  finish  of  the  given  activity.  In 
our  example,  the  free  float  for  Activity  A  is 

FF(A)=ES(J)-EF(A)=9-2=7. 


In  this  example,  the  approach  is  to  find  activi¬ 
ties  having  the  most  free  float  and  try  to  delay 
them  as  long  as  possible  without  delaying 
the  entire  program.  By  delaying  the  start  of 
activity  C  for  2  weeks.  Activities  A  and  B  can 
begin  simultaneously  without  exceeding  the 
limit  of  nine  workers.  Similarly,  Activities  D, 
H,  and  I  can  be  delayed,  resulting  in  the 
revised  personnel  loading  chart  shown  in 
Figure  6-13. 

Figure  6-14  shows  the  revised  schedule 
using  lag  times  to  reflect  the  delays.  It  may 
not  always  be  possible  to  rearrange  the 
schedule  to  stay  within  the  resource  con¬ 
straints.  In  those  cases,  other  steps,  such  as 
adding  more  resources  or  extending  the 
schedule,  will  have  to  be  taken  to  mini¬ 
mize  the  adverse  impact  on  the  program. 
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6.5  SUMMARY 


Network  scheduling  techniques  (PERT, 
CPM,  and  PDM)  are  much  alike  in  provid¬ 
ing  such  things  as  interdependencies,  depth 
of  detail,  a  critical  path,  and  slack.  The 
choice  among  these  three  techniques  de¬ 
pends  primarily  on  the  type  of  program 
and  managerial  objectives.  ThePERT 
method  is  particularly  useful  if  there  is 
considerable  uncertainty  in  program  activ¬ 


Figure6-13.  Revised 


ity  times  and  if  control  of  the  program 
schedule  outweighs  other  factors.  On  the 
other  hand,  CPM  is  more  appropriate  when 
activity  times  can  be  adjusted  readily  and 
when  it  is  important  to  plan  an  appropriate 
tradeoff  between  program  time  and  cost. 
The  PDM  technique  is  best  suited  for  com¬ 
plex  projects  with  different  types  of  rela¬ 
tionships/constraints  between  activities. 
In  reality,  the  proliferation  of  scheduling 
software  has  blurred  many  of  the  differ¬ 
ences  among  network  scheduling,  Gantt, 
and  milestone  techniques. 
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7 

PRODUCTION  SCHEDULING 


7.1  DESCRIPTION 

The  scheduling  techniques  discussed  in 
the  previous  chapters  are  best  suited  for 
one-time  development  projects.  Produc¬ 
tion  scheduling,  as  its  name  implies,  fo¬ 
cuses  on  the  planning,  execution,  and  con¬ 
trol  of  repetitive  activities,  such  as  those 
involved  in  the  manufacture  of  several  iden¬ 
tical  items  using  the  same  processes.  The 
objective  of  production  scheduling  is  to 
balance  the  materials  required  to  produce 
the  items  with  the  production  process  and 
the  delivery  schedule.  Such  scheduling  is 
essential  to  the  efficient  use  of  all  resources 
and  facilities  involved  in  the  manufactur¬ 
ing  process. 

While  the  principles  of  planning  and  sched¬ 
uling  are  essentially  the  same  for  both  situa¬ 
tions,  there  are  differences  that  should  be 
considered.  For  example,  in  the  develop¬ 
ment  phase,  planning  and  scheduling 
should  reflect  the  uncertainty  inherent  in 
development  of  the  product  and  processes 
used.  Consequently,  planning  and  sched¬ 
uling  should  permit  sufficient  flexibility  to 
allow  for  redesign  and  retest  when  inevi¬ 
table  problems  arise.  In  production,  there 
is  less  uncertainty;  the  design  is  relatively 
stable  and  the  processes  to  be  used  are 
fairly  well-defined.  In  general,  more  de¬ 
finitive  constraints  exist  in  production 
scheduling,  such  as  quantities  to  be  pro¬ 
duced,  required  delivery  dates,  and  ca¬ 
pabilities  and  availability  of  production 
assets. 


Production  planning  and  scheduling 
should  be  very  detailed.  A  top-level  project 
schedule  should  serve  as  the  production 
baseline.  It  should  reflect  the  integration  of 
activities  that  different  organizations  in¬ 
volved  in  the  production  process  conduct — 
tooling,  material  procurement,  etc.  Lower 
tier  schedules  should  be  developed  for 
each  of  the  manufacturing  activities,  with 
special  attention  to  those  having  potential 
impact  on  the  delivery  schedule,  e.g.,  ma¬ 
terial  procurement;  tool  design,  fabrica¬ 
tion,  and  prove-out;  test  equipment  prove- 
out;  and  capital  equipment  procurement. 
Thorough  planning  and  integration  of  all 
production  process  activities  are  essential 
to  manage  risk  in  the  manufacturing  ap¬ 
proach.  This  also  provides  assurance  that 
necessary  resources  will  be  available  when 
needed,  that  no  resources  will  be  over¬ 
loaded  or  completely  expended  during 
execution  of  any  manufacturing  task,  and 
that  product  delivery  dates  are  achievable. 

An  understanding  of  the  production  pro¬ 
cesses,  to  include  such  things  as  the  se¬ 
quence  of  operations,  make  or  buy  deci¬ 
sions,  inspection  methods,  tooling,  etc.,  is 
critical  to  effective  production  planning 
and  scheduling.  The  planning  and  sched¬ 
uling  of  all  activities  must  be  fully  inte¬ 
grated  and  reflect  a  synchronized  flow  of 
events  that  result  in  product  or  process 
completion  when  required.  The  produc¬ 
tion  schedule  describing  and  integrating 
such  things  as  the  acquisition  of  required 
materials,  fabrication  flow,  process  times. 
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plant  facilities  to  be  used,  and  personnel 
skills  required  should  be  developed  as  early 
as  possible  in  the  development  process  and 
included  in  the  manufacturing  plan. 

Once  the  planning  and  scheduling  are  com¬ 
plete  and  production  begins,  managers 
need  the  means  to  monitor  progress  and  to 
identify  problem  areas  in  the  process  that 
could  adversely  affect  the  delivery  sched¬ 
ule.  A  technique  that  is  commonly  used  for 
this  purpose  is  the  Line  of  Balance  (LOB) 
technique.  It  graphically  portrays  the  key 
activities  of  the  production  plan  relative  to 
a  required  delivery  schedule  and  provides 
a  view  of  the  progress  being  made  in  each 
activity.  This  enables  managers  to  focus 
their  attention  on  specific  problem  areas  in 
the  process. 

Government  PMs,  except  those  associated 
with  an  activity  that  builds  or  re-builds 
equipment,  will  never  be  responsible  for 
developing  a  production  schedule.  How¬ 
ever,  they  should  understand  the  process 
of  creating  one  because  the  success  of  a 
program  is  very  dependent  upon  the  pro¬ 
ducer  to  plan,  schedule,  and  implement  a 
production  plan. 

The  ensuing  discussion  provides  a  basis 
for  understanding  the  fundamentals  of 
production  planning  and  monitoring.  Most 
companies  have  tailored  planning  software 
programs  to  fit  their  needs,  however  the 
principles  are  the  same  as  those  used  in  the 
LOB  approach.  For  that  reason,  LOB  is  the 
subject  of  discussion. 

The  LOB  technique  consists  of  four  ele¬ 
ments  as  described  below  and  shown  in 
Figure  7-1.  The  application  and  use  of  this 
technique  is  demonstrated  in  a  later  sec¬ 
tion  of  this  chapter. 


7.1.1  Objective  Chart 

An  Objective  Chart  (Figure  7-1A)  is  a  dis¬ 
play  of  the  cumulative  contract  delivery 
schedule  over  time.  It  shows  cumulative 
units  on  the  vertical  scale  and  dates  of 
delivery  along  the  horizontal  scale.  It  also 
shows  actual  cumulative  deliveries  to  date. 

7.1.2  Production  Plan  Chart 

This  chart  (Figure  7-1B)  shows  the  major 
production  process  activities  and  events 
(control  points)  that  are  to  be  monitored 
using  this  technique.  It  also  shows  the  lead- 
time  associated  with  each  of  the  control 
points. 

The  more  steps  that  are  monitored,  the  more 
sensitive  and  more  complicated  the  chart 
becomes.  Generally,  control  points  on  a 
single  chart  should  be  limited  to  50.  If  there 
are  more  than  50,  subsidiary  production 
plans  canbe  used  to  feed  the  top  plan.  Thus, 
each  chart  can  be  kept  simple  and  easy  to 
understand.  The  shipping  date  of  subsid¬ 
iary  charts  is  the  point  at  which  a  subpro¬ 
gram  must  be  ready  to  join  the  overall 
schedule. 

On  the  production  plan  chart,  each  moni¬ 
tored  step  is  numbered,  left  to  right.  Step  1 
has  the  longest  lead  time;  the  shipping  date 
is  the  highest-numbered  step.  When  two 
steps  are  done  at  the  same  time,  they  are 
numbered  from  top  to  bottom,  such  as  steps 
8, 9,  and  10.  These  control  points  can  also  be 
given  symbols  that  show  whether  they  in¬ 
volve  purchased  items,  subcontracted  parts, 
or  parts  and  assemblies  produced  in-house. 
Assemblies  break  down  into  subassemblies, 
which  break  down  into  parts  or  operations. 
Thus,  one  can  develop  a  production  plan  for 
any  part  or  level  of  assembly. 
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Figure  7-1 .  Line  of  Balance  Technique 


The  production  plan  chart  shows  the 
interrelationships  and  the  sequence  of 
major  steps,  as  well  as  lead  times  required 
for  each  step.  An  understanding  of  the 
manufacturing  processes  involved  and 
sound  judgment  are  required  to  know 
which  step  and  how  many  steps  must  be 
monitored.  Slack  or  float  times  for  activi¬ 
ties  are  not  considered  when  plotting  the 
production/lead-time  chart;  only  the  esti¬ 
mated  time  (and  latest  finish  point)  for 
each  activity  is  used. 

The  12  control  points  in  the  production 
plan  chart  shown  in  Figure  7-1B  represent 
key  tasks  in  manufacturing  one  lot  of  mis¬ 
siles.  The  plan  indicates  that  control  point 

(1),  fabricate  ballistics  shell,  must  begin  24 
workdays  before  1  January  to  meet  the  first 
scheduled  delivery  of  five  units  by  the  end 
of  December  (see  the  objective  chart).  The 
lead  time  for  other  control  points  can  be 
related  to  the  scheduled  delivery  in  a  simi¬ 
lar  manner.  Time  for  in-house  transfer  and 
storage  must  be  allowed  in  addition  to  the 
processing  time. 

7.1.3  Program  Status  Chart 

This  chart  (Figure  7-1C)  shows  the  cumula¬ 
tive  inventory  status  at  each  control  point  in 
the  process  at  a  given  time  (in  this  case,  1 
May).  Looking  at  control  point  12,  we  see 
that  the  government  has  accepted  14  units  of 
the  product.  The  ba r  f or  control  point  9  shows 
that  40  units  of  the  guidance  section  have 
been  assembled,  and  the  bar  for  control  point 
4  shows  that  in-house  fabrication  has  begun 
on  60  fins. 

The  cumulative  numbers  of  units  through 
every  control  point  can  and  should  be  meas¬ 
ured  monthly.  Final  deliveries  (government 
acceptances)  are  shown  month-by-month  on 
the  objective  chart  as  actual  deliveries. 


7.1.4  Line  of  Balance 

The  LOB  represents  the  number  of  units  that 
should  have  passed  through  each  control 
point  (cumulatively)  to  satisfy  the  contract 
delivery  schedule.  Managers  use  it  to  ana¬ 
lyze  how  the  status  of  each  control  point  on  a 
given  date  will  affect  future  schedules.  This 
LOB  is  drawn  on  the  Program  Status  Chart 
(Figure  7- 1 C)  using  the  following  procedures: 

(1)  Select  a  control  point;  for  example,  7. 

(2)  From  the  production  plan/lead-time 
chart  (Figure  7-1B),  determine  the  lead  time — 
the  time  from  control  point  7  to  the  shipment 
point.  Government  Acceptance  (12 
workdays). 

(3)  Using  this  number,  determine  the  date 
that  the  unit  now  at  control  point  7  should  be 
completed.  (May  1  +  12  workdays = just  over 
halfway  through  a  22- workday  month.) 

(4)  Find  the  point  corresponding  to  this 
date,  approximately  May  17,  on  the  contract 
schedule  line  and  determine  how  many  units 
scheduled  for  completion  this  represents  by 
moving  horizontally  from  the  objective  chart 
to  the  program  status  chart  (they  share  the 
same  vertical  scale). 

(5)  Draw  a  line  on  the  program  status 
chart  (Figure  7-1C)  at  the  level  (43  units)  over 
control  point  7. 

(6)  Repeat  the  above  for  each  control 
point  and  connect  the  horizontal  lines  over 
the  control  points.  The  resulting  line  is  the 
LOB,  indicating  the  quantities  of  (1)  units 
that  should  have  passed  through  each  con¬ 
trol  point  on  the  date  of  the  study  or  inven¬ 
tory  (1  May)  if  the  contract  delivery  schedule 
were  being  met. 
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The  difference  between  the  LOB  and  the 
top  of  the  bar  for  each  control  point  is  the 
number  of  units  behind  or  ahead  of  sched¬ 
ule  as  of  1  May.  Thus,  control  point  12  is  16 
units  behind  schedule,  control  point  9  is  5 
units  ahead  of  schedule,  and  control  point 
7  is  21  units  behind  schedule.  The  main 
impact  of  control  point  7  being  behind 
schedule  will  be  felt  in  12  workdays,  which 
is  the  lead  time  for  control  point  7.  As  of  1 
April,  an  insufficient  number  of  air  vehicle 
components  (shell,  fins,  engine)  had  passed 
into  the  assembly  (air  vehicle  body)  phase. 
This  will  adversely  affect  final  deliveries 
12  workdays  hence.  All  other  control  points 
can  be  analyzed  in  the  same  way. 

7.2  WHEN  AND  HOW  TO  USE  THE 
LINE  OF  BALANCE  TECHNIQUES 

7.2.1  General 

The  LOB  technique  should  be  considered 
for  use  in  any  project  requiring  the  manu¬ 
facture  of  a  specific  quantity  of  a  product 
using  repetitive  processes.  It  is  an  effective 
technique  for  identifying  those  activities 
that  require  attention  and  possibly  correc¬ 
tive  action  and  can  also  be  used  for  report¬ 
ing  the  status  of  the  manufacturing  process 
and  delivery  schedule  to  higher  manage¬ 
ment.  The  LOB  charts  should  be  updated 
on  a  periodic  basis  (weekly  or  monthly, 
depending  on  such  factors  as  the  size  of  the 
production  run,  the  number  of  activities/ 
control  points,  and  the  level  of  automated 
data  management). 

Government  managers  will  probably  not 
be  involved  with  the  LOB  technique  in  the 
day-to-day  management  of  their  programs. 
However,  they  should  have  a  basic  under¬ 
standing  of  the  technique,  the  type  of  infor¬ 
mation  it  can  convey,  and  its  applicability. 


7.2.2  Analysis 

Using  the  LOB  charts  in  Figure  7-1,  man¬ 
agement  can  tell  at  a  glance  how  actual 
progress  compares  with  planned  progress. 
Analysis  of  the  charts  can  pinpoint  prob¬ 
lem  areas.  Delays  at  control  point  7  in  the 
example  may  have  been  causing  final  de¬ 
livery  problems  throughout  the  contract. 
However,  the  purpose  of  LOB  analysis  is 
not  to  show  what  caused  the  slippage  in  the 
shipping  date,  but  to  detect  potential  fu¬ 
ture  problems. 

In  the  example,  the  Government  accep¬ 
tance  point  is  control  point  12.  The  bar 
doesn't  reach  the  LOB;  therefore,  deliver¬ 
ies  are  behind  schedule.  Control  points  10 
and  11  are  short.  However,  point  9  is  on 
schedule.  Since  point  10  depends  on  points 
8  and  9,  we  know  control  point  8  is  the 
offender.  Both  points  7  and  8  are  short,  but 
there  are  more  than  enough  purchased 
items  (engines)  at  control  point  6. 

What's  the  problem  with  control  point  8? 
Trace  it  back  to  control  point  7,  which  is 
seriously  short.  It  is  obvious  that  not  hav¬ 
ing  enough  completed  fins  is  holding  up 
the  whole  process.  Control  points  2, 3  and 
5  are  short,  but  are  not  directly  responsible 
for  the  failure  to  meet  the  delivery  sched¬ 
ule  since  9  is  ahead  of  schedule.  Neverthe¬ 
less  shortages  at  2,  3,  and  5  could  soon 
cause  problems  at  9.  The  problem  with  the 
fins  7  should  be  addressed  before  manage¬ 
ment  attention  is  devoted  to  other  short 
operations.  The  overages  at  control  points 
1  and  6  may  be  examined  from  the  point  of 
view  of  inventory  control.  Updating  the 
charts  requires  a  good  status-reporting  sys¬ 
tem,  which  can  be  mechanized  if  the  pro¬ 
gram  is  large  and  complex. 
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7.3  LINE  OF  BALANCE  ADVANTAGES 
AND  DISADVANTAGES 

7.3.1  Advantages 

(1)  Points  out  problems  before  their 
impact  on  finished  product  deliveries  show 
up,  thereby  allowing  managers  to  correct 
problems  earlier. 

(2)  Allows  managers  to  see,  in  the 
middle  of  a  contract,  whether  they  can 
meet  the  contract  schedule  if  they  continue 
working  as  they  have  been. 

(3)  Focuses  attention  on  those  pro¬ 
duction  control  points  where  there  are  prob¬ 
lems;  this  allows  a  senior  manager  to  pin¬ 
point  responsibility  for  slippages. 

7.3.2  Disadvantages 

(1)  People  working  on  a  project  may 
not  grasp  what  the  LOB  is  measuring. 

(2)  Limited  to  production  and/or 
assembly-type  processes. 

(3)  Shows  only  where  the  problem 
is,  not  what  it  is. 

(4)  A  monitoring  device;  not  as  easy 
to  use  as  a  planning  device. 

7.4  SUMMARY 

The  LOB  is  a  monitoring  technique  that 
gives  prior  warning  of  problems  within  a 
continuous  production  process.  The  key  is 
to  catch  problems  in  a  production  process 
early;  otherwise,  the  schedule  is  lost.  The 
LOB  technique  provides  that  warning. 


Think  of  the  production  process  as  a  natu¬ 
ral  gas  pipeline.  If  a  bubble  of  air  gets 
into  the  pipeline,  it  will  eventually  be 
carried  to  the  gas  users,  and  the  users 
will  find  their  burners  extinguished  as 
the  nonflammable  air  reaches  them.  The 
manager  of  the  pipeline  company  or  the 
natural  gas  utility  doesn't  want  clients  to 
suffer  blowouts  from  air  bubbles  in  their 
lines.  The  same  holds  true  for  the  manag¬ 
ers  of  a  continuous  production  process. 
Waiting  for  problems  to  show  up  at  the 
end  of  the  line  is  a  mistake.  Problems 
need  to  be  detected  when  they  begin  so 
corrections  are  faster,  before  too  much 
damage  (to  cost,  performance,  or  sched¬ 
ule)  is  done,  and  production  schedules 
fall  too  far  off  contract. 

To  do  LOB,  the  following  is  needed:  (1)  a 
contract  schedule,  or  objective  chart;  (2)  a 
production  plan  or  lead-time  chart  for 
the  production  process  itself;  (3)  control 
points  cumulative  inventories;  and  (4)  a 
program  status  chart  on  which  to  plot 
LOB  and  the  cumulative  quantities  of 
units  that  have  passed  through  the  con¬ 
trol  points  of  the  assembly /production 
process.  If  the  objective  and  program 
status  charts  are  given  the  same  vertical 
scale,  the  LOB  can  be  plotted  graphically 
from  the  former  to  the  latter. 

Remember  that  the  shape  of  the  LOB  will 
change  over  time,  especially  if  the  produc¬ 
tion  process  has  a  beginning  and  an  end. 
Remember,  too,  that  LOB  charts  show 
where  a  problem  is,  but  not  necessarily 
why  the  problem  exists  or  what  the 
solution  is. 
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8 

TIME  MANAGEMENT 


In  most  programs,  especially  in  DoD  and 
defense-related  industries,  time  is  a  re¬ 
source  that  must  be  carefully  managed.  If 
it  is  not,  it  can  become  a  serious  constraint 
that  can  threaten  the  success  of  the  pro¬ 
gram.  This  chapter  addresses  time  man¬ 
agement  from  two  perspectives:  first,  as  it 
relates  to  a  program,  and  second,  as  it 
relates  to  the  PMs  use  of  time. 

8.1  TIME  MANAGEMENT  AND 
THE  PROGRAM 

This  section  concerns  three  aspects  of  time 
management  related  to  programs: 

(1)  Time  reserve 

(2)  "Now"  schedule 

(3)  Value  of  time. 

8.1.1  Time  Reserve 

In  contractor  performance  measurement, 
much  emphasis  is  placed  on  "management 
reserve,"  the  reserve  budget  controlled  by 
the  industry  PM.  What  isn't  always  recog¬ 
nized  is  that  a  time  reserve  is  also  needed  in 
order  to  accommodate  unknowns  in  the  pro¬ 
gram.  However,  use  of  a  time  reserve  should 
be  approached  with  caution,  because  mem¬ 
bers  of  a  program  office  team  may  be  tempted 
to  fall  back  on  it  prematurely. 

Literature  describing  time  reserve  is  scarce. 
However,  there  are  some  aspects  of  a  time 
reserve  that  are  clear. 


(1)  Most  PMs  establish  a  time  reserve  of 
about  10  percent.  On  a  40-month  program, 
for  example,  a  4-month  time  reserve  would 
be  established. 

(2)  The  time  reserve  must  be  held  closely 
by  the  PM.  Otherwise,  every  manager  on 
his/her  program  may  think  "I  know  there's 
a  time  reserve;  therefore,  I  don't  really 
have  to  meet  my  schedule."  The  PM  may 
place  this  reserve  under  "additional  sys¬ 
tem  tests"  or  another  downstream  activity. 
The  point  is,  it  shouldn't  be  visible.  (A 
built-in  safety  factor  between  the  manufac¬ 
turing  schedule  and  the  delivery  schedule 
is  often  used.) 

(3)  A  tough  and  disciplined  approach  to 
meeting  the  published  schedule  is  required 
from  the  start  of  a  program  in  order  to 
maintain  the  reserve  and,  consequently,  to 
meet  the  program  schedule  in  spite  of  slip¬ 
pages  caused  by  the  unknown  unknowns 
(unk-unks)  that  inevitably  arise. 

8.1.2  "Now"  Schedule 

There  is  a  direct  relationship  between  time 
and  cost  for  any  activity.  This  relationship 
takes  into  account  the  people,  resources, 
and  method  used.  It  also  considers  the 
efficiency  achieved.  Generally,  the  least 
costly  schedule  is  the  current  one.  Speed¬ 
ing  up  the  schedule  costs  more;  stretching 
out  the  schedule  also  costs  more. 

The  sum  of  the  direct  and  indirect  costs 
gives  a  U-shaped  total  program  cost  curve. 
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The  optimum  schedule  for  implementing 
the  program  is  the  schedule  corresponding 
to  the  minimum  point  on  this  curve.  The 
relationship  among  direct,  indirect,  and 
total  program  cost  is  shown  graphically  in 
Figure  8-1. 

Because  schedule  stability  affects  program 
costs,  which  may,  in  turn,  affect  technical 
performance,  it  is  clear  that  schedule  sta¬ 
bility  has  a  great  deal  to  do  with  whether 
the  program  meets  its  cost  and  technical 
objectives.  Unfortunately,  budget  con¬ 
straints  and  other  factors,  like  changes  in 
quantities  (items  over  which  the  PM  has  no 
control),  have  often  been  imposed  on  a 
program  with  the  comment,  "Do  the  best 
you  can." 

When  a  schedule  must  be  revised,  the  super¬ 
seded  schedule  is  often  discarded.  If  the 
new  schedule  is  superseded,  the  process  is 
repeated.  However,  there  is  some  value  in 
retaining  an  obsolete  schedule.  Often,  the 


organization  causing  a  slip  in  schedule 
becomes  a  repeat  offender.  The  principal 
value  of  retaining  a  former  schedule  lies  in 
being  able  to  hold  the  offender's  feet  to  the 
fire,  thus  making  schedule  slips  less 
palatable. 

The  significance  of  maintaining  a  stable 
schedule  is  becoming  more  widely  recog¬ 
nized.  Appendix  A  describes  the  develop¬ 
ment  of  a  master  schedule  and  the  impor¬ 
tance  of  maintaining  schedule  discipline. 

8.1.3  Value  of  Time 

According  to  the  late  John  H.  Richardson, 
president  of  Hughes  Aircraft  Company, 
"A  basic  reason  for  adopting  project  (or 
program)  management,  when  tackling  the 
difficult  and  unique  tasks  associated  with 
developing  and  producing  a  system,  is  to 
eliminate  unnecessary  delays  in  accom¬ 
plishing  the  job  at  hand.  Time  is  a  resource 
in  systems  management,  to  be  treated  with 


Figure  8-1.  Total  Cost  Analysis  for  Selecting 
“Optimum”  Program  Duration 
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indifference  or  used  well  like  any  other 
resource.  For  projects  not  yet  in  full  swing, 
it  is  important  to  recognize  that  time  has 
economic  value,  and  that  we  may  be  taking 
time  too  much  for  granted."1 

(1)  Funding  could  create  a  problem.  In 
hungry  years,  the  schedule  is  often  stretched 
because  of  reduced  funding. 

(2)  A  better  product  could  be  developed 
if  it  were  more  thoroughly  debugged  and 
tested.  However,  a  system  does  not  really 
get  wrung-out  until  it  is  in  the  user's  hands, 
regardless  of  advance  debugging. 

(3)  Cost  of  concurrency  (overlap  of  devel¬ 
opment  and  production)  might  lead  to  a 
decision  not  to  overlap  program  phases. 
Such  a  decision  might  be  popular  in  many 
cases,  but  it  could  never  be  tolerated  when 
the  pendulum  swings  toward  the  impor¬ 
tance  of  time;  that  is,  when  top  manage¬ 
ment  says,  "Get  the  system  out  the  door, 
never  mind  what  it  costs."2 

Stretched-out  schedules  incur  cost  penal¬ 
ties  because  of  inflation,  additional  engi¬ 
neering  changes,  and  changes  in  key  pro¬ 
gram  management  office  positions.  An¬ 
other  near-term  cost  is  due  to  the  increased 
chance  that  a  program  will  be  canceled 
because  of  obsolescence  or  competing  tech¬ 
nology.  Stretch-outs  invite  cancellation. 
Also,  long  schedules  with  no  opportunities 
for  incorporation  of  improvements  are  a 
negative  factor  when  considering  a  new 
start. 

Delayed  decisions  increase  costs.  Accord¬ 
ing  to  R.  W.  Peterson,  former  DuPont  execu¬ 
tive,  "All  businessmen  are  concerned,  and 
properly  so,  about  the  long  time  it  takes  to 
move  a  new  development  from  its  incep¬ 
tion  to  a  profit  status.  But  frequently 


forgottenisthefactthatamonth'sdelayinthe 
early  stages  of  development  is  exactly  as 
long  as  a  month's  delay  in  the  later  stages. 
While  it  may  seem  innocuous  to  put  off  a 
decision  for  a  month  or  two  in  the  early  years 
of  a  project  (or  program)  with  an  uncertain 
future,  that  delay  may  turn  out  to  be  just  as 
costly  as  is  procrastination  when  the  final 
decisions  are  made.  In  short,  a  sense  of  ur¬ 
gency  is  essential  to  decision  making  in  all 
stages  of  a  new  venture,  not  just  the  later 
stages."3 

The  useful  life  of  a  defense  system  must  be 
taken  into  consideration.  Concentration  on 
the  system  or  product  often  overlooks  a  key 
point:  whether  the  buyer  obtains  value  upon 
delivery.  The  most  costly  product  is  one  that 
appears  when  it  no  longer  fulfills  a  useful 
purpose,  even  though  it  has  been  produced 
at  minimum  cost.  Each  month  added  to  the 
development  and  production  of  a  new  high- 
technology  system  or  product  tends  to  re¬ 
duce  by  1  month  the  operational  life  of  the 
system  or  product. 

In  spite  of  the  10-20  percent  cost  premium 
that  may  be  paid  for  tight  scheduling  (as 
compared  to  orderly  but  stretched-out  sched¬ 
uling),  the  resulting  longer  operational  life 
may  provide  greater  economic  value.  This  is 
looking  at  time  only  from  the  viewpoint  of 
economics,  i.e.,  acquisition  cost  per  year  of 
operational  availabil  survival  insurance. 

Consideration  of  alternative  plans  and  sched¬ 
ules  will  also  help;  e.g.,  if  event  so-and-so 
occurs,  proceed  with  plan  A;  if  event  such- 
and-such  occurs,  proceed  with  plan  B  and  so 
on.  Anticipation  and  preparation  for  most- 
likely  events,  along  with  the  tools  described, 
and  coupled  with  effective  communication 
of  the  plans,  can  change  the  management 
style  from  crisis  management  to  skillful 
management. 
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8.2  TIME  MANAGEMENT  AND  THE 
PROGRAM  MANAGER4 

PMs  are  busy  people.  They  have  the  re¬ 
sponsibility  for  the  management  of  a 
myriad  of  activities  and  the  resources  that 
make  up  the  program.  In  addition,  they  are 
often  required  to  perform  specific  program 
activities,  especially  in  smaller  programs. 
Thus,  it  is  important  that  they  manage  their 
time  well.  Some  managers  could  be  more 
productive,  perhaps  as  much  as  20-40  per¬ 
cent,  by  better  managing  their  time.  A  major 
difficulty  in  accomplishing  this  is  the  fail¬ 
ure  to  realize  that  there  is  a  time  manage¬ 
ment  problem  and  that  solutions  are  pos¬ 
sible.  This  section  discusses  various  as¬ 
pects  of  time  management  and  identifies 
ways  to  better  accomplish  it. 

In  the  early  1980s,  a  time  management 
survey  was  conducted  to  identify  the  prob¬ 
lems  in  achieving  effective  time  manage¬ 
ment.  More  than  300  project  managers  in 
24  industries,  including  the  government, 
participated  in  the  survey,  which  investi¬ 
gated  15  different  areas.  The  survey  iden¬ 
tified  several  time  management  problem 
areas.  Among  the  most  common  were  time 
robbers  and  meetings. 

Time  robbers  are  simply  those  things  that 
can  occur  on  a  day-to-day  basis  that  can 
take  away  from  the  PMs  ability  and  time  to 
accomplish  his/her  work.  There  are  liter¬ 
ally  dozens,  if  not  hundreds,  of  such  things, 
such  as  incomplete  work,  delayed  deci¬ 
sions,  poor  communications  channels,  ca¬ 
sual  visitors,  lack  of  effective  program 
management  tools,  etc.  Appendix  B  con¬ 
tains  a  list  of  common  time  robbers.  The 
survey  found  that  delayed  decisions  and 
poor  communications  were  the  most  com¬ 
monly  cited  time  robbers.  Another  com¬ 
mon  problem  that  affects  a  PMs  time  is  the 


inability  or  reluctance  to  say  no.  If  a  subor¬ 
dinate  brings  a  problem  to  the  PM,  the 
Manager  must  be  alert  to  make  sure  not  to 
assume  responsibility  for  the  problem, 
unless,  of  course,  the  situation  warrants 
such  action.  If  subordinates  believe  that 
PMs  will  assume  responsibility  for  their 
problems,  needless  demands  on  the  PM's 
time  will  increase. 

Meetings  are  a  fact  of  life  in  program  man¬ 
agement.  However,  unless  they  are  effec¬ 
tively  planned  and  conducted,  they  can  be 
a  severe  drain  on  time  and  resources.  A 
number  of  common  pitfalls,  if  not  avoided, 
can  turn  meetings  into  a  complete  waste  of 
time.  Among  them  are:  not  having  a  clear 
and  focused  agenda;  spending  too  much 
time  on  trivial  matters;  having  too  many  or 
too  few  meetings;  not  having  the  right 
people  at  the  meetings;  and  not  keeping  an 
accurate  record  of  decisions  and  actions 
assigned. 

To  get  the  most  value  out  of  meetings,  the 
following  actions  should  be  considered: 

(1)  Understand  the  purpose  of  the  meeting 
and  what  results  are  expected 

(2)  Minimize  the  number  of  people  attend¬ 
ing  the  meeting 

(3)  Hold  the  meeting  in  a  setting  appro¬ 
priate  for  the  meeting  objectives 

(4)  Develop  and  distribute  the  agenda 

(5)  Start  and  finish  on  time 

(6)  Summarize  meeting  results  and  pre¬ 
pare  and  distribute  minutes. 

In  addition  to  focusing  on  time  robbers 
and  the  conduct  of  meetings,  PMs  should 
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also  concentrate  on  other  effective  time 
management  techniques,  such  as: 

(7)  Prioritize  activities 

(8)  Devote  solid  time  blocks  for  important 
activities 

(9)  Maintain  "to  do"  lists  and  time  logs 

(10)  Delegate 

(11)  Manage  by  exception 

(12)  Practice  calculated  neglect 

(13)  Control  access — limit  casual  visits  and 
telephone  calls. 

8.3  SUMMARY 

Planning  and  scheduling  can  do  much  to 
prevent  running  out  of  time  and  having  to 


make  the  least  desirable  decision  because 
of  lack  of  time.  Establishing  a  time  reserve 
and  a  "now"  schedule,  and  recognizing  the 
value  of  time  in  decision  making  all  con¬ 
tribute  to  the  PMs  repertoire  of  good  tools. 

Sir  Jeffrey  Quill,  manager  of  the  British 
Spitfire  Development  Program,  com¬ 
mented  during  a  visit  to  DSMC  that;  "After 
1935,  costs  weren't  particularly  important. 
What  mattered  was  time.  We  worked  three 
shifts  a  day.  Everything  was  time.  Quan¬ 
tity  and  time.  It  turned  out  that  we  prob¬ 
ably  produced  at  the  lowest  cost,  too;  but 
the  emphasis  was  on  time." 

PMs  must  manage  their  time  effectively  if 
they  are  to  be  successful.  They  must  be 
alert  to  those  time  robbers  that  affect  their 
ability  to  accomplish  their  work  and  un¬ 
derstand  the  value  of  proven  time  manage¬ 
ment  techniques. 
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AUTOMATED  SCHEDULING  TOOLS 


Previous  chapters  have  shown  that  manag¬ 
ers  use  schedules  in  a  variety  of  ways  for  a 
wide  range  of  purposes.  Schedules  are  an 
integral  part  of  the  program  planning  and 
decision  processes.  Managers  use  them  to 
track  progress,  predict  future  work,  man¬ 
age  resources,  analyze  alternatives,  iden¬ 
tify  risk,  and  report  program  status.  In 
most  cases,  it  is  the  PMs  responsibility  to 
construct,  revise,  maintain,  and  report 
schedule  information. 

The  PM  must  do  these  things  in  a  complex 
environment  that  cuts  across  contractor 
and  government  boundaries  and  includes 
a  wide  geographical  area.  The  challenge  is 
complicated  even  further  by  the  need  for 
instant  information  that  must  be  available 
to  a  wide  audience  that  usually  requires 
the  information  in  a  specific  format  to  suit 
unique  needs. 

It  would  be  impossible  to  meet  these  chal¬ 
lenges  without  automated  tools. The 
remainder  of  this  chapter  discusses  charac¬ 
teristics  and  features  of  some  tools  avail¬ 
able  on  the  market  today  and  suggests 
criteria  that  anyone  searching  for  a  tool 
should  consider.  The  intent  is  to  provide  an 
overview  of  the  types  of  products  that  are 
available  and  the  range  of  functions  these 
products  support.  The  level  of  detail  pre¬ 
sented  is  keyed  to  what  would  be  useful  to 
know  about  the  program  management  soft¬ 
ware  tools  that  would  likely  be  used  in  a 
mid-to-large  Program  Office. 


9.1  AUTOMATED  PLANNING  AIDS 

The  idea  to  use  the  power  of  the  computer 
to  assist  in  the  planning  and  tracking  pro¬ 
cess  is  not  new.  Industry  has  used  auto¬ 
mated  scheduling  software  for  at  least  the 
past  30  years.  Early  versions  of  these  tools, 
however,  usually  employed  a  mainframe 
computer  that  batch  processed  data  off¬ 
line  and  spewed  reams  of  information  for 
managers  to  analyze  when  they  arrived  at 
work  on  a  Monday  morning.  Despite  the 
automated  tools,  the  process  of  creating, 
maintaining,  and  reporting  schedule  in¬ 
formation  was  a  daunting  task. 

The  advent  of  PCs /workstations  and  net¬ 
work  technologies  has  made  life  easier  for 
managers.  The  market  encourages  soft¬ 
ware  vendors  to  develop  a  wide  range  of 
programs  readily  available  to  P  Ms  to  aid 
them  in  effectively  and  efficiently  dealing 
with  the  details  involved  in  creating  a  pro¬ 
gram  plan,  then  tracking  progress. 

The  introductory  paragraph  of  this  chap¬ 
ter  lists  many  uses  of  a  "schedule."  Soft¬ 
ware  developers  have  responded  to  the 
managers'  needs  by  creating  programs 
that  build  schedules  and  support  pro¬ 
gram  management  functions.  Even  the 
simplest  program  includes  some  program 
management  features.  The  focus  of  the 
following  discussion,  therefore,  is  on  the 
broad  category  of  Program  (often  called 
Project)  Management  Software. 


The  focus  is  on  providing  a  brief  descrip¬ 
tion  of  the  functionality  of  these  products, 
highlighting  some  of  the  desirable  features 
that  are  available  to  support  program 
management,  and  identifying  sources  that 
may  be  useful  in  determining  what  prod¬ 
ucts  are  available  and  how  their  features 
and  performance  might  be  assessed. 

9.2  FUNCTIONAL  CHARACTERISTICS 

AND  FEATURES 

Most  of  the  Program  Management  Soft¬ 
ware  that  is  available  today  is  based  on  a 
relational  database  design  and  is  therefore 
able  to  support  a  broad  range  of  program 
management  activities  including: 

(1)  Scheduling/Tracking 

(2)  Resource  Planning /Management 

(3)  Risk  Management 

(4)  Cost/Performance/Analysis 

(5)  Reports  and  Graphics. 

The  extent  to  which  the  different  programs 
support  these  activities  varies  from  prod¬ 
uct  to  product.  For  example,  some  prod¬ 
ucts  provide  the  capability  to  create  only 
Gantt  charts  whereas  others  provide  the 
tools  to  make  Gantt  and  network  charts. 

Program  features,  the  way  in  which  activi¬ 
ties  are  implemented,  are  an  important 
factor  in  considering  the  usefulness  of  a 
program.  A  convenient  way  to  profile  the 
functional  characteristics  and  associated 
features  of  automated  program  manage¬ 
ment  tools  is  to  do  so  from  these  three 
perspectives: 


(1)  System-Level  Characteristics 

(2)  Project  Management/Scheduling 
Characteristics 

(3)  Ease  of  Use. 

System-level  features  have  a  general 
applicability,  independent  of  any  of  the 
specific  project-management  activities  sup¬ 
ported,  that  add  to  the  overall  capability 
and  desirability  of  the  product.  These  fea¬ 
tures  include,  but  may  not  be  limited  to: 

•  Collaboration/Workgroup — Enables 
managers /team  members  to  use  a  com¬ 
mon  system  of  communication  and  allow 
access  to  common  databases  for  the  pur¬ 
pose  of  assigning  tasks,  updating  project 
data,  assigning  resources,  and  reporting 
status. 

•  Integral  e-mail — Allows  exchange  of 
messages  and  file  attachments  to  other 
project  team  members  from  within  the 
project  management  application. 

•  Multiple  Project/Multiple  Tasks — 

Supports  multiple  programs  and  tasks 
within  a  project. 

•  Security — Limits  access  to  certain  data 
by  individual  or  class  of  user,  as  well  as 
password  protection  for  the  system. 

•  Open  Data  Base  Connectivity 
(ODBC) — Enables  users  to  import  data 
from  other  data  sources  and  in  various 
formats  into  their  scheduling  applications 
(e.g.,  data  from  your  contractor's  project 
database).  This  is  a  Microsoft-developed 
standard  for  exchanging  data  with  a  vari¬ 
ety  of  databases. 
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Most  programs  include  features  that  focus 
on  program  management  and  schedule 
functions.  Some  features  offered  are: 

•  Project  Scheduling/Tracking — Data 
Entry  Templates  facilitate  the  entry  of  the 
initial  task,  time,  and  resource  data.  On- 
Screen  Tracking  facilitates  comparison  of 
actual  performance  versus  the  planned  and 
allows  tracking  of  progress  by  cost,  time,  or 
achievement. 

•  Resource  Planning/Management — Re¬ 
source  Leveling  is  a  capability  that  resolves 
resource  conflicts  by  delaying  tasks  and 
assignments  as  well  as  by  task  splitting, 
which  entails  dividing  tasks  into  segments 
with  time  gaps  as  necessary.  Resource  Cal¬ 
endars  provide  insight  into  the  availability 
of  a  particular  resource  by  showing  work¬ 
ing  and  non- working  times.  Free/Total  Slack 
Time  is  a  feature  that  is  useful  for  adjusting 
under-or-over  allocated  resources. 

•  Cost/Performance  Analysis — Earned 
Value  Tools  are  essential  for  comparing  ac¬ 
tual  performance  with  expected  perform¬ 
ance.  Cost  Analysis  Tool  Kits  are  tools  for 
analyzing  data  and  making  forecasts.  This 
feature  may  be  integral  to  the  product  or 
available  by  virtue  of  "exporting"  data  to 
another  application  with  this  capability. 

•  Reports  and  Graphics — Pre-Defined  Re¬ 
ports  facilitate  the  presentation  of  project 
data.  Customization  Controls  provide  users 
with  a  convenient  way  to  format  reports  to 
their  own  specifications.  Filters  enable  the 
user  to  screen  information,  e.g.,  tasks  or 
resources,  before  capturing  a  screen-view 
or  preparing  a  report.  Embedded  Graphics 
and  Text  capability  allows  a  user  to  import 
data  from  other  applications  for  inclusion 
in  a  project  report. 


•  Import/Export — Import/Export  data 
from /to  an  external  source,  such  as  an¬ 
other  database  or  spread  sheets,  facilitates 
the  ability  to  create  custom  reports  or  con¬ 
duct  analyses. 

Finally,  ease  of  use  or  user  friendliness,  is 
the  set  of  qualities  that  represent  the  degree 
in  which  people  can  employ  the  software 
without  an  inordinate  amount  of  training 
or  regular  reference  to  user's  manuals.  User 
friendliness  is  an  important  consideration 
because  program  management  software 
products  can  be  complicated.  Regardless 
of  how  powerful  a  program  may  be,  if  it  is 
difficult  to  use,  managers  probably  will 
not  spend  the  time  to  learn  it.  Consequently, 
PM  software  is  likely  to  be  effective  and 
desirable  if  users  can  easily  learn  to  use  it. 

The  following  features  typify  user-friendly 
systems: 

•  Graphical  User  Interfaces  (GUIs) — 

These  are  the  screens  in  which  a  user  inter¬ 
acts  with  the  program.  The  operating  envi¬ 
ronments  in  use  today  have  led  to  the 
development  of  interface  screens  that  en¬ 
able  the  user  to  interact  with  the  software 
in  an  intuitive  way,  using  a  variety  of 
buttons,  menu  lists,  and  wizards. 

•  On-Screen  Data  Entry — The  capability 
to  create  schedule  information  by  using 
tools  to  create  an  on-screen  graph.  See  Fig¬ 
ure  9-1  for  an  example. 

•  Help  Function — On-screen  docu¬ 
mentation  as  well  as  "context-sensitive" 
help  in  which  the  software  displays  the 
applicable  text  based  on  the  functions  be¬ 
ing  performed.  This  is  a  particularly  useful 
feature  for  someone  learning  to  use  it. 
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Figure  9-1.  On  -Screen  Data  Entry  Using  Gantt  Chart  Feature 
(AEC  Software  Fast  Track  Schedule) 


•  T utorials — Program  instruction  on  per¬ 
forming  certain  functions  and  guidance 
through  a  "canned"  demonstration. 

•  Wizards — Templates  that  guide  the 
user  through  various  project  setup,  data 
entry,  and  report  formatting  procedures. 
The  features  discussed  above  are  a  sample 
of  the  characteristics  of  various  program 
management  products.  Moreover,  there  is 
no  common  "feature  list"  or  set  of  defini¬ 
tions  that  defines  the  various  characteris¬ 
tics.  Nonetheless,  the  summary  should  give 
a  sense  of  what  is  available  and  provide  the 
basis  for  a  more  exhaustive  review  as 
needed. 


9.3  EVALUATING  PROJECT 

MANAGEMENT  SOFTWARE 
PRODUCTS 

Choosing  a  software  program  from  the 
wide  range  of  available  products  can  be 
complex  and  time  consuming.  The  selec¬ 
tion  process  should  begin  with  an  analysis 
of  what  managers  want  to  do  with  the 
software  to  identify  the  functions  that  are 
needed.  Other  factors  that  should  be  part 
of  the  assessment  process  are  consider¬ 
ation  of  personnel  skill  levels /training  re¬ 
quirements,  integration  with  enterprise 
(organizational)  systems,  hardware/sys¬ 
tem  requirements,  and  cost. 
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Table  9-1.  Project  Management  Software  Functions  and  Criteria 


Feature 


Graphical  User  Interfaces  (GUIs) 


Robust  Help  Function 


Wizards 


Tools 


Tutorials 


On-Screen  Data  Entry 


Collaboration/Workgroup  Support 


Integral  e-mail 


Multi-Project  &  Task  Support 


Security 


Open  Data  Base  Connectivity 


USER  FRIENDUNESS 


Consideration 


Logical,  intuitive,  all  inclusive,  windows  compliant 


Complete,  easy  to  access,  context  based,  examples 


Exist  for  major  functional  areas,  intuitive,  tailorable  results 


Exist  for  major  functional  areas,  intuitive 


Complete  and  examples 


Simple,  logical,  complete,  intuitive 


SYSTEM  LEVEL  FEATURES 


Desired  capabilities  available,  non-proprietary 


Exists,  simple,  compatibility  with  existing  e-mail 


Roll-up  to  higher  levels,  supported  by  reporting  features 


Meets  specific  security  needs,  compatible  w/  existing  system 


Data  transfer  with  other  program  management  S/W 


PROJECT  MANAGEMENT/SCHEDULING  FUNCTIONS 


Multiple  Schedule  Methods 


Roll-Up 


Ability  to  Tailor  to  Specific  Needs 


Relationships 


Progress  Tracking 


Critical  Path  Display 


Project  Scheduling/Tracking 


Create  Gantt,  network  charts,  and  go  from  one  to  the  other 


Display  and  report  different  levels 


Add/delete/modify  activity  and  event  information 


Display  and  report  dependencies  among  events/activities 


Compare  and  display  plans  and  actual  progress 


Highlight  critical  path 


Interoperability  w/  Other  Programs  |  Import  and  export  data  from  other  programs 


Total  Free/Slack  Time 


Time  Estimates 


Time  Roll-Up 


Resource  Determination 


Resource  Assignment 


Compute  and  display  free  and  slack  time 


Use  probability  distributions  to  compute  time  to  complete 


Use  statistical  methods  to  compute  roll-up  times 


Resource  Planning/Management 


Assist  in  determining  resources  needed 


Allow  assignment  and  notification  of  assignment  to  activities 


Interoperability  w/  Other  Programs  Import  and  export  resource  data 


Resource  Leveling 


Resource  Calendars 
Task  Assignment 


Schedule  Analysis 
Earned  Value  Analysis 


Cost  Analysis 
Resource  Analysis 


Pre-Defined  Report  Formats 


Customization  Controls 


Embedded  Graphics  and  Text 


Easy  to  access,  permits  “what  if”  excursions 
Display  resources  overtime 
Filter  and  display  assignment  of  responsibility 
Analysis 

Allow  analysis  and  comparison  of  alternative  schedules 
Assist  in  complete  and  accurate  EV  analysis 
Includes  tool  kits  for  analysis  of  program  cost 


Compute  resource  utilization,  identify  conflicts 


Reports 


Automatically  create  reports  based  on  program  data 


Allow  reports  to  be  tailored  for  specific  purposes 


Add  text  and  graphics  to  reports 


Analyses  of  requirements  and  software 
evaluation  are  beyond  the  scope  of  this 
discussion.  However,  Table  9-1  shows  some 
of  the  functions  that  are  available  in  avail¬ 
able  program  management  software  and 
lists  some  ideas  for  consideration  when 
searching  for  the  right  software. 

9.4  FINDING  OUT  MORE 

The  best  method  of  gaining  information 
about  a  potential  project  management  tool 
is  to  talk  to  someone  who  is  using  the 
product.  A  PM  in  the  next  office  may  have 
a  perfectly  acceptable  and  proven  product 
that  he/she  is  using.  The  company  under 
contract  may  have  a  product  that  it  uses.  If 
the  government  and  contractor  program 


offices  are  going  to  share  information,  it  is 
prudent  to  use  the  same  software,  if  pos¬ 
sible.  At  the  very  least,  compatibility  and 
interoperability  must  be  demonstrated  be¬ 
fore  making  a  decision  to  buy  a  particular 
product. 

There  is  a  considerable  information  on 
project  management  and  scheduling  soft¬ 
ware  from  a  variety  of  sources.  The  Defense 
Acquisition  Deskbook  (DAD)  has  a  list  of 
tools  that  are  being  used  by  program  of¬ 
fices.  From  a  commercial  aspect,  specific 
product  information  is  available  on  most 
companies'  World  Wide  Web  home  pages. 
Virtually  all  developers  provide  informa¬ 
tion  about  their  products  on  a  web  site  and 
show  links/ contact  to  additional  sources. 
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APPENDIX  A 


INTEGRATED  MASTER  SCHEDULE  DESCRIPTION 


The  Integrated  Master  Schedule  (IMS)  for  a 
program  should  be  a  time  reference  baseline 
for  the  activities  and  events  that  make  up 
the  program.  It  should  be  incorporated 
into  the  program  plan  and  linked  to  ap¬ 
proved  performance  and  cost  objectives. 
The  IMS  is  developed  by  the  contractor 
from  the  Integrated  Master  Plan  (IMP), 
which  documents  all  the  tasks  required  to 
deliver  a  high  quality  product  and  to  facili¬ 
tate  success  throughout  the  product's  life 
cycle.  In  an  Integrated  Product  and  Process 
Development  (IPPD)  environment,  which 
is  the  standard  approach  for  all  DoD  pro¬ 
grams,  the  IMP  and  IMS  provide  an 
overarching  framework  against  which  the 
Integrated  Product  Teams  (IPTs)  can  func¬ 
tion,  helping  them  understand  their  work 
within  the  context  of  the  total  program. 

The  IMP  and  IMS  evolve  as  the  program 
matures.  During  the  initial  stages  of  Con¬ 
cept  Exploration,  the  integrated  plan  is 
preliminary  and  its  purpose  is  to  provide 
an  understanding  of  the  scope  of  work 
required  and  the  likely  structure  of  the 
program.  It  is  constructed  to  depict  a  likely 
progression  of  work  through  the  remain¬ 
ing  phases,  with  the  most  emphasis  on  the 
current  and  /  or  upcoming  phase  (especially 
the  period  to  be  contracted  for  next).  As  the 
program  is  defined,  the  IMP  is  iterated 
several  times,  each  time  increasing  the  level 
of  detail  and  confidence  at  which  all  essen¬ 
tial  work  has  been  identified.  The  specific 
format  for  this  plan  is  not  critical;  however, 
it  usually  reflects  an  Event/ Accomplish¬ 
ment/Criteria  hierarchical  structure — a 


format  that  greatly  facilitates  the  tracking 
and  execution  of  the  program. 

In  some  cases,  a  preliminary  IMP  and  its 
corresponding  IMS  may  be  developed  by 
the  government  but  include  industry  in¬ 
puts  obtained  through  open  communica¬ 
tions  with  potential  sources  during  the 
pre-solicitation  phase  of  the  acquisition. 
Contractors  are  normally  required  to  sub¬ 
mit  formal  IMP  and  IMS  with  their  propos¬ 
als  and  to  develop  more  detailed  IMP/ 
IMS  versions  after  the  contract  is  awarded. 

The  IMS  is  event  driven  and  is  developed 
with  participation  of  all  program  stake¬ 
holders.  It  should  identify  all  tasks  that 
need  to  be  accomplished,  their  logical  or¬ 
der,  and  the  input  conditions  necessary  to 
complete  each  task.  When  documented  in 
a  formal  plan  and  schedule,  this  event- 
driven  approach  can  help  ensure  that  all 
tasks  are  integrated  properly  and  that  the 
management  process  is  based  on  signifi¬ 
cant  events  in  the  acquisition  life  cycle  and 
not  on  arbitrary  calendar  events.  Develop¬ 
ing  the  program  schedule  presents  an  op¬ 
portunity  to  identify  critical  risk  areas.  As 
IPT  members  estimate  the  times  to  com¬ 
plete  specific  tasks,  events  that  may  cause 
delays  will  become  apparent.  These  events 
are  potential  areas  of  risk  that  the  IPT 
should  consider  for  further  analysis. 

The  IMS  begins  as  an  IMP  with  dates — the 
starting  points  are  the  events,  accomplish¬ 
ments,  and  criteria  that  make  up  the  plan. 
At  a  minimum,  an  IMS  shows  the  expected 
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start  and  stop  dates  for  each  activity  in  the 
plan,  but  each  activity  maybe  broken  down 
into  lower-level  tasks  that  will  be  used  to 
manage  the  program  on  a  day-to-day  ba¬ 
sis.  The  schedule  can  be  expanded  down¬ 
ward  to  the  level  of  detail  appropriate  for 
the  scope  and  risk  of  the  program.  Pro¬ 
grams  with  high  risk  show  much  lower 
levels  of  detail  in  the  integrated  master 
schedule  in  order  to  give  the  visibility 
necessary  to  manage  risk.  The  more  de¬ 
tailed  the  IMS,  however,  the  greater  the 
cost  to  track  and  update  the  schedule. 
Under  acquisition  reform  initiatives,  the 
dates  in  the  IMS  usually  are  not  made 
contractually  binding  so  as  to  allow  the 
flexibility  to  take  full  advantage  of  event- 
driven  scheduling. 

Additional  information  on  the  development 
of  IMSs  can  be  found  in  various  sections  of 
the  Defense  Acquisition  Deskbook  and  in  the 
DoD  Integrated  Product  and  Process  Develop¬ 
ment  Handbook  dated  August  1998.  Com¬ 
mercial  standards  EIA  632  and  IEEE  1220- 
1994  can  also  be  consulted  for  more  infor¬ 
mation  on  developing  master  plans  and 
schedules.  See  http:  /  / www.eia.org/ eng/ 
published.htma  n  d  http:/  / 
standards.ieee.org  for  information  on 
how  to  obtain  these  standards.  A  DoD 
Data  Item  Descriptor  (DI-MISC-81183A) 
has  been  developed  for  IMS  guidance; 
it  is  attached  to  this  Appendix  as  Tab  1. 

USE  OF  INTEGRATED  MASTER 
SCHEDULES 

The  primary  purpose  of  the  IMS  is  to  track 
schedule  variations.  By  linking  the  IMS  to 
the  IMP,  it  can  also  be  used  to  track  the 
activities  that  provide  functional  and  life- 
cycle  inputs  to  product  development.  In 
this  role  it  provides  a  crosscheck  not  only 
that  the  inputs  were  obtained,  but  also  that 


they  were  obtained  at  the  right  time.  In 
addition,  the  IMS  can  be  useful  for  the 
following  events /activities  that  are  com¬ 
mon  to  all  programs. 

PROGRAM  REVIEWS 

The  IMS  can  be  a  framework  for  periodic 
program  reviews  within  the  program  man¬ 
agement  office  (PMO).  If  constructed  prop¬ 
erly,  the  schedule  will  illustrate  the  vari¬ 
ous  levels  of  the  program  and  will  be  com¬ 
patible  with  the  program  cost/schedule 
control  system  reports. 

Program  reviews  can  be  an  excellent  forum 
for  resolution  of  schedule  conflicts  and  the 
genesis  for  controlled  changes  to  the  sched¬ 
ule  from  within  the  PMO.  Most  key  mem¬ 
bers  of  the  PMO  team  are  present  at  these 
reviews;  therefore,  proposed  schedule 
changes  or  slips  can  receive  wide  dissemi¬ 
nation  within  the  organization. 

WHAT  IF"  EXERCISES 

The  IMS  can  serve  as  the  framework  for 
"what  if"  exercises  imposed  on  programs 
from  outside  the  PMO.  Schedule  changes 
can  be  plotted  manually  by  using  over¬ 
lays.  Using  the  same  grid  coordinates  on 
an  overlay  allows  the  PMO  team  to  see, 
clearly  and  graphically,  the  effect  of  the 
compressions  or  extensions  of  sub-mile¬ 
stones  on  the  program.  It  may  be  even 
easier  (and  more  productive)  for  the  PMO 
team  to  run  "what  if"  exercises  on  a  com¬ 
puterized  schedule.  Without  a  master 
schedule  as  a  baseline,  these  exercises  can 
take  longer  to  accomplish  and  they  may 
overlook  important  variances  from  the 
program's  established  baseline  schedule 
or  plan. 
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PROGRAM  BRIEFINGS 

The  IMS  can  serve  as  a  baseline  for  pro¬ 
gram  reviews  at  higher  headquarters  and 
other  reviews  or  briefings  outside  the  PMO. 
Most  programs  have  key  milestones  taken 
from  the  master  schedule  and  presented  in 
summary  form  on  viewgraphs  or  slides.  If 
these  do  not  show  the  detail  required  to 
make  a  point,  the  time  span  shown  can  be 
reduced  to  the  point  where  the  details 
become  visible. 

SCHEDULE  DISCIPLINE 

To  be  effective,  an  IMS  must  be  kept  up- 
to-date  and  accurate.  Maintenance  of  the 
IMS  requires  a  process  similar  to  that 
inherent  in  configuration  control — one 
that  establishes  discipline  through  a  set  of 
rigorous  procedures  for  managing  sched¬ 
ule  change.  The  degree  of  schedule  disci¬ 
pline  imposed  within  the  PMO  can  be  a 
major  factor  in  the  success  of  a  program. 
The  underlying  philosophy  of  the  sched¬ 
ule  control  process  should  reflect  central¬ 
ized  control  of  the  IMS.  That  is,  changes  to 
the  IMS  baseline  should  be  made  only 
with  the  approval  of  the  PM  or  his/her 
designated  representative  and  with  full 


justification  and  an  understanding  of  the 
impact  of  the  changes  on  the  overall  pro¬ 
gram.  Following  are  examples  of  some 
simple  procedures  that,  if  practiced,  will 
instill  discipline  and  prevent  the  unautho¬ 
rized  release  of  schedule  information  that 
has  not  been  approved  for  inclusion  in  the 
IMS. 

•  Program  changes,  whatever  the  source, 
should  start  as  proposals  and,  if  approved, 
grow  into  a  firm  plan.  Eventually,  they  are 
incorporated  into  the  IMS  as  changes.  The 
question  of  when  to  plot  these  changes  is  a 
matter  of  judgment  and  should  reflect  the 
PM's  policy.  Each  change  should  be  plot¬ 
ted  as  a  proposed  or  tentative  change  until 
approved. 

•  A  permanent  record  of  each  change 
should  be  maintained.  If  the  program 
schedule  slips,  it  should  be  documented 
until  documentation  no  longer  serves  a 
useful  purpose. 

•  Whenever  copies  of  the  IMS  are  made, 
they  should  be  dated  and  authenticated  by 
the  signature  of  the  PM  or  the  appointed 
schedule  manager.  Undated  and  unauthen¬ 
ticated  schedules  should  not  be  released 
outside  the  PMO. 
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DATA  ITEM  DESCRIPTION 


Form  Approved 
OMB  NO.  07040188 


Pubiicrepcr  ting  burden  for  thiscdledion  of  information  iaestimated  toeverage  1  lOhouraper  reaper  se,  including  thetimefor  reviewing  instrudions,  searching  aisting  data  sources,  gdhenng  and  mantamng  the 
data  nested,  and  completing  and  reviewing  thecolledicn  cf  informaiicn.  Send  commits  regarding  this  burden  eetimdecr  any  <*her  asped  d  this  cdl  edion^  Information,  induing  sugg^ions 
burden,  toDepa'tment  of  Defense,  Washington  Headquarters  Services,  Director  ate  for  Information  Operations  and  Reports,  1215Jefferscn  Davis  Highway,  Sute  1204  Arlington,  VA  222024302  and  to  the  Off  iced 
Managanant  and  Budget,  Paperwork  Reduction  Projed  (0704016$,  Washington,  DC  20503 


1.  TITLE 

Integrated  Master  Schedule  (IMS) 


2.  I DENTI  FI  CATION  NUMBER 

DI-MI  SC-81 183  A 


3.  DESCRIPTION/PURPOSE  .  ,  ,  .  .  , 

The  IMS  is  an  integrated  schedule  developed  by  logically  networking  detailed  program 

activities.  The  contract  Integrated  Master  Plan  (IMP)is  the  foundation  of  the  program 

schedule  and  provides  a  hierarchy  for  schedule  traceability  and  summarization.  IMP  events, 

accomplishments,  and  criteria  are  included  In  the  schedule  to  monitor  progress.  This 

information  will  be  used  to  verify  attainability  of  program  objectives,  evaluate  the  progress 

of  the  government  and  contractor  team  toward  meeting  the  program  objectives,  and  to  integrate 


4.  APPROVA  L  DATE  (YYMMDD) 

5.  OFFICE  OF  PRIMARY  RESPONSIBILITY  (OPR) 

6a  OTIC  APPLICABLE 

6b.  GIDEP APPLICABLE 

960209 

F/ASC/FMCS 

7.  APPLICATION/INTERRELATIONSHIP  ...  ... 

7.1  This  Data  Item  Description  (DID)  contains  the  format  and  content  preparation 
instructions  for  the  data  product  generated  by  the  specific  and  discrete  task  requirement  as 
delineated  in  the  contract. 


7.2  This  DID  may  be  applied  to  programs  which  utilize  the  Work  Breakdown  Structure  (WBS) 
during  the  concept  exploration,  demonstration  and  validation,  engineering  and  manufacturing 
and  development,  and  production  phases. 


7.3  This  DID  supersedes  DI-MISC-81183. 


8.  APPROVAL  LIMITATION 


9a  APPLICABLE  FORMS 


10.  PREPARATION  INSTRUCTIONS  .  x  .  .  .  ..  , 

10.1  Format  .  This  precedence  logic  diagram  shall  be  in  the  contractor’s  format  in  the  form 
of  a  network,  milestone,  and  Gantt  chart.  This  diagram  shall  be  provided  in  digital  format. 


).  AM 9C NUMBER 

F7180 


1 0.2  Content  .  The  schedule  shall  contain  all  of  the  contract  IMP  events  and  milestones, 
accomplishments,  criteria,  and  activities  from  contract  award  to  the  completion  of  the 
contract.  The  schedule  shall  be  an  integrated,  logical  network-based  schedule  that 
correlates  to  the  program  WBS,  and  is  vertically  and  horizontally  traceable  to  the 
cost/schedule  reporting  instrument  used  to  address  variances  (such  as  Cost  Performance  Report 
(CPR),  Cost/Schedule  Status  Report  (C/SSR),  etc.)  It  shall  have  a  numbering  system  that 
provides  traceability  through  the  IMP  and  Statement  of  Work  (SOW) .  It  shall  contain  program 
events  and  milestones  and  definitions,  summary,  intermediate  and  detailed  schedules,  and 
periodic  analysis  of  progress  to  date.  It  shall  be  possible  to  access  the  information  by 
product,  process,  or  organizational  lines.  Descriptions  of  the  key  elements  are  as  follows: 

10.2.1  Program  milestones  and  definitions. _  Key  programmatic  events  defined  by  IMP,  the 

contracting  agency  or  weapon  system  contractor  which  define  progress  and  completion  in  each 
WBS  element  along  with  the  definition  for  successful  completion  of  the  milestone. 


1 0.2.2  Summary  master  schedules.  A  graphical  display  of  top-level  program  activities  and 

key  events  and  milestones  of  the  IMP  which  depict  major  work  activities  in  an  integrated 
fashion  at  the  summary  level  of  the  WBS,  e.g.  level  1  -3  of  the  WBS. 

1 1 0.2.3  Intermediate  schedules.  A  graphical  display  of  top-level  program  activities  and  key 

milestones  which  includes  all  associated  accomplishments  of  the  IMP,  traceable  to  the  WBS 
element  as  necessary  to  display  the  work  effort  at  the  Intermediate  level  of  summarization, 
e.g.  level  3-5  of  the  WBS  as  appropriately  tailored. 

E 1 0.2.4  Detailed  schedules.  A  graphical  display  of  detailed  activities  and  milestones  which 
depict  work  activities  in  a  particular  work  breakdown  structure  element,  to  include  the 
criteria  associated  with  each  accomplishment  of  the  WBS  element  as  well  as  any  additional 
activities  necessary  to  display  the  work  effort  to  detailed  WBS  levels,  e.g.  level  4-8  of  the 
WBS  as  appropriately  tailored. 


11.  DISTRIBUTION  STATEMENT  . .  . 

Distribution  Statement  A:  Approved  for  public  release;  distribution  is  unlimited. 
DD  Form  1 664,  APR  89  Previous  editions  are  obsolete 


Page  JLot  _3_ 


74 


04/15/91 


DI-MI  SC-81 183 


Block  1 0,  Preparation  Instructions  (Continued) 

1 0-2.5  Periodic  analysis.  A  brief  summary  which  identifies  progress  to  date,  variances  to  the  planned 
schedule,  causes  for  the  variance,  potential  impacts  and  recommended  corrective  action  to  avoid 
schedule  delays.  For  each  program  milestone  planned,  forecasted  and  actual  completion  dates  shall  be 
reported.  The  analysis  shall  also  identify  potential  problems  and  a  continuing  assessment  of  the  network 
critical  path.  Thresholds  for  impact  reporting  shall  be  identified  on  the  DD  Form  1423,  CDRL. 

10.2.6  Integrated  program  network.  Logical  diagram  of  all  activities  in  the  program.  The  key  elements  of 
the  integrated  network  to  be  constructed  in  the  diagram  are  as  follows: 

a.  Milestone  or  event  -  A  specific  definable  accomplishment  in  the  program/project  network,  recognizable 
at  a  particular  point  in  time.  Milestones  are  numbered  and  may  be  contained  within  an  activity  box. 

b.  Activity  or  task  -  A  time  consuming  element,  e.g.  work  in  progress  between  interdependent  events, 
represented  by  an  activity  box. 

c.  Duration  -  Planned  length  of  time  needed  to  accomplish  an  event/activity. 

d.  Relationships  -  A  line  that  defines  how  two  activities  or  events  are  logically  linked.  It  can  take  up  to 
four  (4)  forms: 


(1)  FS  (finish  to  start)  -  An  activity  must  finish  before  another  can  start. 

(2)  SS  (start  to  start)  -  An  activity  depends  on  the  start  of  another 

activity. 

(3)  FF  (finish  to  finish)  -  One  activity  cannot  finish  until  another  activity 

is  finished. 

(4)  SF  (start  to  finish)  -  An  activity  cannot  finish  until  another  activity 

starts. 

e.  Slack  or  Float  -  Extra  time  available  on  an  activity  before  it  will  impact  an  activity  on  the  critical  path. 

f.  Lag  -  The  delay  or  wait  period  between  two  tasks. 

g.  Critical  Path  -  A  sequence  of  activities  in  the  network  that  has  the  longest  total  duration  through  the 
program  or  project.  Activities  along  the  critical  path  have  zero  or  negative  slack/float.  It  should  be  easily 
distinguished  on  the  report  formats,  e.g.  a  thick  line,  patterned  or  in  red  ink.  This  should  be  calculated  by 
computer-based  software. 

h.  Target  Start  (TS)  -  A  program  defined  date  of  when  an  activity  should  start.  This  is  an  operator- 
defined  date  rather  than  a  computer-calculated  date. 

i.  Target  Complete  (TC)  -  A  program  defined  date  of  when  an  activity  should  finish.  This  is  an  operator- 
defined  date  rather  than  a  computer-calculated  date. 

j.  Actual  Start  (AS)  -  Actual  start  date  of  an  activity. 

k.  Actual  Finish  (AF)  -  Actual  finish  date  of  an  activity. 

l.  Early  Start  (ES)  -  The  earliest  start  date  an  activity  can  begin  the  precedence  relationships.  Computer- 
calculated  date. 

m.  Early  Finish  (EF)  -  The  earliest  finish  date  an  activity  can  end.  Computer-calculated  date. 

n.  Late  Start  (LS)  -  The  latest  start  date  an  activity  can  start  without  delaying  the  program  or  project 
target  completion  date.  Computer-calculated  date. 
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Block  10,  Preparation  Instructions  (Continued) 

o.  Late  Finish  (LF)  -  The  latest  finish  date  an  activity  can  have  without  affecting  the  program  or  project  target  completion  date. 
Computer-calculated  date. 

p.  Percent  Complete  (PC)  -  Actual  progress  of  an  activity  from  its  start  to  its  finish. 

Master  Integrated  Program  Schedule. _  It  shall  display  all  of  the  proposed  activities,  events,  and  milestones 

from  contract  award  to  the  completion  of  the  contract. 

10-4  Descriptive  titles. _  Activities,  tasks,  events,  and  milestones  shall  be  labeled  with  a  brief  descriptive  title, 

numbered  of  coded  and  contain  time  constraints  (e.g.  duration,  TS,  ES,  EF,  LS,  LF,  etc.).  Standard  abbreviations  may  be 
used  to  conserve  space.  Descriptive  titles  used  on  activities,  events,  and  milestones  shall  be  identical  on  all  program  schedules. 
A  legend  shall  be  provided  to  aid  in  ease  of  reading  the  schedules. 

1 0.5  Schedule  risk.  The  schedule  shall  include  a  description  of  the  approach  that  will  be  taken  to  limit  the  schedule 
risks  identified  as  a  result  of  the  contractor’s  risk  assessment.  Risk  shall  be  defined  considering  impact  on  cost  and  technical 
performance  and  assessing  the  probability  of  schedule  change.  Additionally,  technical  performance  measurement  tasks  and 
their  correlation  with  contractual  cost/schedule  elements  permit  assessment  of  the  program  effort  in  terms  of  the  schedule 
as  well  as  cost  of  work  increments.  As  technical  performance  measurement  tasks,  as  well  as  cost  reviews,  reveal  potential 
impacts  to  the  schedule  these  risks  will  be  identified. 

1  °*5.1  Schedule  Risk  Assessment  (SR A). _  Optimistic,  pessimistic,  and  most  likely  durations  for  each  MIPS 

activity/task  and  milestone/event  shall  be  provided  as  the  basis  for  determining  the  probability  of  meeting  schedule  dates. 

The  government  will  assess  the  durations  and  use  an  appropriate  cumulative  probability  (0-1 00%)  for  the  chosen  milestones 
to  determine  expected  completion  dates. 
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APPENDIX  B 

Common  Time  Robbers  1 


•  Incomplete  work 

•  A  job  poorly  done  that  must  be  done 
over 

•  Poor  communications  channels 

•  Uncontrolled  telephone  calls 

•  Lack  of  adequate  responsibility  and 
commensurate  authority 

•  Poor  functional  performance  and 
status  reporting 

•  Changes  without  direct  notification/ 
explanation 

•  Casual  visitors  and  conversations 

•  Waiting  for  people 

•  Failure  to  delegate,  or  unwise 
delegation 

•  Poor  retrieval  systems 

•  Lack  of  information  in  a  ready-to-use 
format 

•  Day-to-day  administration 

•  Spending  more  time  than  anticipated 
in  answering  questions 

•  Late  appointments 

•  Impromptu  tasks 

•  Having  to  explain  "thinking"  to 
superiors 

•  Too  many  levels  of  review 

•  Too  many  people  in  a  small  area 


•  Misplaced  information 

•  Record  keeping 

•  Shifting  priorities 

•  Indecision  or  delaying  decisions 

•  Procrastination 

•  Setting  up  appointments 

•  Too  many  meetings 

•  Monitoring  delegated  work 

•  Unclear  roles /job  descriptions 

•  Unnecessary  crisis  intervention 

•  Need  to  get  involved  in  details  to  get 
job  done 

•  Not  enough  proven  or  trustworthy 
managers 

•  Vague  goals  and  objectives 

•  Too  many  people  involved  in  minor 
decision  making 

•  Lack  of  technical  knowledge 

•  Lack  of  authorization  to  make 
judgment  decisions 

•  Unreasonable  time  constraints 

•  Lack  of  commitment  from  higher 
authorities 

•  Too  much  travel 

•  Lack  of  adequate  project  management 
tools 
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•  Poor  functional  communications/  writ 
ing  skills 

•  Inability  to  relate  to  peers  in  a  personal 
way 

•  Rush  into  decisions/beat  the  deadline 

•  Lack  of  reward  ("a  pat  on  the  back  can 
do  wonders") 

•  Expecting  too  much  from  one's  staff 
and  oneself 

•  Going  from  crisis  to  crisis 

•  Conflicting  directives 

•  Fire  drills 

•  Lack  of  privacy 

•  Lack  of  challenge  in  job  duties 

•  Bureaucratic  roadblocks  ("ego") 

•  Empire-building  line  managers 

•  Too  much  work  for  one  person  to  handle 
effectively 

•  Excessive  paperwork 

•  Lack  of  clerical  /administrative  support 

•  Workload  growing  faster  than  capacity 


•  Dealing  with  unreliable  subcontractors 

•  Personnel  not  willing  to  take  risks 

•  Demand  for  short-term  results 

•  Lack  of  long-range  planning 

•  Being  overdirected 

•  Overreacting  management 

•  Poor  lead  time  on  projects 

•  Documentation  (reports/red  tape) 

•  Large  number  of  projects 

•  Inadequate  or  inappropriate  require¬ 
ments 

•  Desire  for  perfection 

•  Lack  of  dedication  by  technical  experts 

•  Lack  of  project  organization 

•  Constant  pressure 

•  Constant  interruptions 

•  Project  budget  problems 

•  Shifting  of  functional  personnel 

•  Lack  of  qualified  manpower 


_ ENDNOTES _ 

1  Harold  Kerzner,  Project  Management,  Van  Norstand  Reinhold,  New  York,  NY,  1998,  Chapter  6. 
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APPENDIX  C 

GLOSSARY 


ACQUISITION  STRATEGY  —  A  busi¬ 
ness  and  technical  management  approach 
designed  to  achieve  program  objectives 
within  the  resource  constraints  imposed.  It 
is  the  framework  for  planning,  directing, 
contracting  for,  and  managing  a  program. 
It  provides  a  master  schedule  for  research, 
development,  test,  production,  fielding, 
modification,  postproduction  manage¬ 
ment,  and  other  activities  essential  for  pro¬ 
gram  success.  Acquisition  strategy  is  the 
basis  for  formulating  functional  plans  and 
strategies  [e.g.,  test  and  evaluation  master 
plan  (TEMP),  acquisition  plan  (AP),  com¬ 
petition,  prototyping,  etc.]. 

ACTIVITY — A  task  or  measurable  amount 
of  work  to  complete  a  job  or  part  of  a 
project. 

ACTUAL  COST  OF  WORK  PER¬ 
FORMED  (ACWP)  —  The  costs  actually 
incurred  and  recorded  in  accomplishing 
the  work  performed  within  a  given  time 
period. 

ARROW  DIAGRAM  METHOD  (ADM) 

—  A  type  of  network  diagram  that  labels 
the  activities  on  the  lines  connecting  nodes. 

BAR  CHART  —  The  detailed  graphical 
working  plan  of  a  part  providing  sequence 
and  time  for  the  job  scheduled  ahead  and 
progress  to  date. 

BUDGETED  COST  OF  WORK  SCHED¬ 
ULED  (BCWS)  —  The  sum  of  the  budgets 
for  all  work  (work  packages,  planning  pack¬ 


ages,  etc.)  scheduled  to  be  accomplished 
(including  in-process  work  packages),  plus 
the  amount  of  level  of  effort  and  appor¬ 
tioned  effort  scheduled  to  be  accomplished 
within  a  given  time  period.  (Planned  Value) 

BUDGETED  COST  OF  WORK  PER¬ 
FORMED  (BCWP)  —  A  measurement  of 
work  performed  in  cost/ schedule  control 
systems  criteria  (C/SCSC)  terminology. 
BCWP  is  a  measurement  of  work  performed 
as  compared  to  the  original  plan.  (Earned 
Value) 

BUDGETING  —  The  process  of  translat¬ 
ing  resource  requirements  into  a  funding 
profile. 

CRITICAL  PATH  METHOD  (CPM)  —  A 

technique  that  aids  understanding  of  the 
dependency  of  events  in  a  project  and  the 
time  required  to  complete  them.  Delayed 
activities  that  have  an  impact  on  the  total 
project  schedule  are  critical  and  said  to  be 
on  the  critical  path. 

EARNED  VALUE  MANAGEMENT  SYS¬ 
TEM  (EVMS)  —  An  integrated  manage¬ 
ment  system  that  coordinates  work  scope, 
schedule,  and  cost  goods  and  objectively 
measures  progress  toward  these  goals.  It  is 
based  on  an  industry-developed  set  of  32 
guidelines  adopted  for  use  by  DoD  in  1999 
for  evaluation  of  contractor  management 
systems.  A  complete  listing  of  the  guide¬ 
lines  is  contained  in  DoD  5000.2- R,  Appen¬ 
dix  VI. 
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FLOAT — The  period  of  time  that  an  activ¬ 
ity  may  be  delayed  without  becoming  a 
critical  activity.  Also  known  as  slack  or 
path  float/slack. 

FREE  FLOAT  —  The  float  that  a  single 
activity  can  experience  without  affecting 
any  other  activity. 

GANTT  CHART — A  graphic  portrayal  of 
a  project  which  shows  the  activities  to  be 
completed  and  the  time  to  complete  repre¬ 
sented  by  horizontal  lines  drawn  in  pro¬ 
portion  to  the  duration  of  the  activity.  Some 
Gantt  charts  will  be  able  to  show  the  float 
for  the  activity. 

INTEGRATED  MASTERPLAN  (IMP)  — 

An  event-based  plan  that  depicts  the  over¬ 
all  structure  of  the  program  and  the  key 
processes,  activities,  and  milestones.  It  de¬ 
fines  the  accomplishments  and  criteria  for 
each  event  in  the  plan. 

INTEGRATED  MASTER  SCHEDULE 
(IMS)  —  The  detailed  task  and  timing  of 
the  work  effort  in  the  IMP.  A  networked 
schedule  that  identifies  all  IMP  events, 
accomplishment,  and  criteria,  and  the  ex¬ 
pected  dates  of  each. 

INTEGRATED  PRODUCT  AND  PRO¬ 
CESS  DEVELOPMENT  (IPPD) — A  man¬ 
agement  technique  that  simultaneously 
integrates  all  essential  acquisition  activi¬ 
ties  through  the  use  of  multidisciplinary 
teams  to  optimize  the  design,  manufactur¬ 
ing,  and  supportability  processes.  IPPD 
facilitates  meeting  cost  and  performance 
objectives  from  product  concept  though 
teamwork  through  Integrated  Product 
Teams  (IPTs). 


INTEGRATED  PRODUCT  TEAM  (IPT) 

— Team  composed  of  representatives  from 
all  appropriate  functional  disciplines  work¬ 
ing  together  to  build  successful  programs, 
identify  and  resolve  issues,  and  make 
sound  and  timely  recommendations  to  fa¬ 
cilitate  decision  making.  There  are  three 
types  of  IPTs:  overarching  IPTs  (OIPTs) 
focus  on  strategic  guidance,  program  as¬ 
sessment,  and  issue  resolution;  working 
IPTs  (WIPTs)  identify  and  resolve  program 
issues,  determine  program  status,  and  seek 
opportunities  for  acquisition  reform;  and 
program-level  IPTs  focus  on  program  ex¬ 
ecution  and  may  include  representatives 
from  both  government  and  after  contract 
award  industry. 

LINE  OF  BALANCE  (LOB)  —  A  graphic 
display  of  scheduled  units  versus  actual 
units  produced  over  a  given  set  of  critical 
schedule  control  points  on  a  particular  day. 

MASTER  PROGRAM  SCHEDULE 
(MPS)— The  top-level  schedule  for  the  pro¬ 
gram.  It  is  prepared  by  the  government 
and  includes  all  policy  and  contractual 
events/activities.  It  is  derived  from  the 
Program  WBS  and  provides  the  baseline 
for  all  subordinate  schedules.  It  some¬ 
times  is  called  the  program  structure/ 
schedule. 

MILESTONE  (MS)  —  The  point  when  a 
recommendation  is  made  and  approval 
sought  regarding  starting  or  continuing 
(proceeding  to  next  phase)  an  acquisition 
program.  Milestones  are:  0  [Approval  to 
Conduct  Concept  Studies],  I  [Approval  to 
Begin  a  New  Acquisition  Program],  II  [Ap¬ 
proval  to  Enter  Engineering  &  Manufac¬ 
turing  Development  (EMD)],  and  III  [Pro¬ 
duction  or  Fielding/Development  and 
Operational  Support  (PF/DOS)  approval]. 
A  significant  event  that  marks  certain 
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progress,  such  as  completion  of  a  phase  of 
the  project. 

MILESTONE  CHART  —  A  graphic 
portrayal  of  a  program/project  that  shows 
the  events  to  be  completed  on  a  timeline. 

NETWORK  SCHEDULE  —  A  scheduling 
technique  that  provides  the  means  for  de¬ 
fining  task  relationships  and  relationship 
lags.  These  may  include  such  precedence 
relationships  as  "Start  to  Start,"  "Finish  to 
Finish,"  and  "Start  to  Finish." 

PERT  —  See  Program  Evaluation  Review 
Technique. 

PERT  Chart — A  graphic  portrayal  of  mile¬ 
stones,  activities,  and  their  dependency 
upon  other  activities  for  completion  and 
depiction  of  the  critical  path. 

PRECEDENCE  DIAGRAM  METHOD — 

A  network  diagram  in  which  the  activities 
are  labeled  in  the  nodes,  usually  boxes. 

PRODUCTION  SCHEDULES— Chrono¬ 
logical  controls  used  by  management  to 
regulate  efficiently  and  economically  the 
operational  sequences  of  production. 

PROGRAM  EVALUATION  REVIEW 
TECHNIQUE  (PERT)  —  A  technique  for 
management  of  a  program  from  inception 
through  to  completion  by  constructing  a 
network  model  of  integrated  activities  and 
events  and  periodically  evaluating  the 
time/cost  implications  of  progress. 

RESOURCE  LEVELING  —  A  process 
whereby  resources  are  sorted  out  among 
tasks  and  activities  to  identify  and  avoid 
conflicts  between  scheduling  and  avail¬ 
ability. 


RISK  —  A  measure  of  the  inability  to 
achieve  program  objectives  within  defined 
cost  and  schedule  constraints.  Risk  is  asso¬ 
ciated  with  all  aspects  of  the  program,  e.g., 
threat,  technology,  design  processes,  work 
breakdown  structure  (WBS)  elements,  etc. 
It  has  two  components:  the  probability  of 
failing  to  achieve  a  particular  outcome  and 
the  consequences  of  failing  to  achieve  that 
outcome. 

RISK  MANAGEMENT  —  All  plans  and 
actions  taken  to  identify,  assess,  mitigate, 
and  continuously  track,  control,  and  docu¬ 
ment  program  risks. 

SCHEDULE  —  Series  of  things  to  be  done 
in  sequence  of  events  within  given  period; 
a  timetable. 

SCHEDULE  RISK  —  The  risk  that  a  pro¬ 
gram  will  not  meet  its  acquisition  strategy 
schedule  objectives  or  major  milestones 
established  by  the  acquisition  authority. 

SCHEDULE  VARIANCE  —  A  metric  for 
the  schedule  performance  of  a  program.  It 
is  the  algebraic  difference  between  earned 
value  (BCWP)  and  planned  value  (BCWS) 
(Variance  =  BCWP  -  BCWS).  A  positive 
value  is  a  favorable  condition  while  a 
negaive  value  is  unfavorable. 

SCHEDULING — The  prescribing  of  when 
and  where  each  operation  necessary  to  the 
manufacture  of  a  product  is  to  be  per¬ 
formed. 

WORK  BREAKDOWN  STRUCTURE 
(WBS)  —  An  organized  method  to  break 
down  a  project  into  logical  subdivisions  or 
subprojects  at  lower  and  lower  levels  of 
details.  It  is  very  useful  in  organizing  a 
project.  See  MIL-HDBK  881  for  examples 
ofWBSs. 
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